rror message or crashing on closing program

[JosDuchIt]

On closing gui4cli (renamed g4t when compiled for tests) i almost always get an error message:
"returned with unfreed signals 20000000! "

the exception being a crash.
The stacktrace does not seem to tell me much (does not refer tot gui4cli source but to

native kernel module kernel+0x00012450
native kernel module dos.library.kmod+0x00028648 etc

The only place in the crashlog mentions the crashing app is :

Background CLI [guis:g4t] (Crashed)
Stack: 0x5a624004 - 0x5a633ffc, pointer @ 0x5a633c40 (Cookie OK)
Signals: SigRec 0x00000020, SigWait 0x00000100
State: Process (Crashed)


Questions
- what is the error message telling me? what can be the origin of such an error?
- is there some overview available of system error messages?
- can the info on the crashlog be exploited to narrow down the problem? Whuch parts and how?
- other suggestions to nail the crasherrormessage cause?
Thanks in advance

[abalaban]

- what is the error message telling me? what can be the origin of such an error?

The error message is telling you that your program exits but has not freed signal bit 20000000. It's either a signal you allocated by yourself directly or a signal allocated by an object that you forgot to dispose. It indicates that probably you are at lest leaking memory at worst leaving some objects/structures in memory with invalid data in them...

- is there some overview available of system error messages?

I don't understand the question, do you want a list of error code ?

- can the info on the crashlog be exploited to narrow down the problem? Whuch parts and how? (/quote]

You are facing one of the most annoying problem we have when dealing with GUI under AmigaOS, if your GUI doesn't follow the rules you can crash the whole system. In such condition the crash is not in your program but in the system itself because your program leaved the system with invalid data. There is no easy way to know what is causing the crash, except trying to find and solve this unfreed signal (which is probably linked to your problem)

- other suggestions to nail the crasherrormessage cause?

The message has nothing to do with your crash, at least not directly. In fact it's a warning that something was not cleared/disposed correctly at exit. I can only advise you to check allocation/disposition of all of your objects/structures.

[JosDuchIt]

@abalaban

thanks

The error message is telling you that your program exits but has not freed signal bit 20000000. It's either a signal you allocated by yourself directly or a signal allocated by an object that you forgot to dispose. It indicates that probably you are at lest leaking memory at worst leaving some objects/structures in memory with invalid data in them...

I don't understand the question, do you want a list of error code ?

A list of system error messages, with some explanation about them: possible or most probable cause, relation with language constructs, with parts of the system (library, kernel)

here in this case :
- what is a signal ? How does the OS uses it? How is it related to objects/stuctures for which memory was allocated? (example of a case that will generate such error message? Will any unfreed object/stucture generate a similar error message,maybe with an other signal bit identified?
- Why does the error message identifies the 'signal bit' if this can not in any way be related to some helpfull information?
I can readily understand a message that would tell me 'object/stucture not freed' so i am guessing system people that defined the error messages had some exploitation of that info in mind?

You are facing one of the most annoying problem we have when dealing with GUI under AmigaOS, if your GUI doesn't follow the rules you can crash the whole system. In such condition the crash is not in your program but in the system itself because your program leaved the system with invalid data. There is no easy way to know what is causing the crash, except trying to find and solve this unfreed signal (which is probably linked to your problem)

The gui4cli program i am talking about is an interpreter, allowing to easily create a gui. It probably does not generate the error message, when no Gui4Cli 'gui defining' script is loaded and interpreted before closing the program. So i guess i'll have to identify the gui's that do generate that error message.
edited:
I just tested without opening any gui (apart from a file requester and the standrd Gui4Cli "loading/opening/closing gui's" requester, and i do have the same error message. in a way that too narrows down the code i should check.

[abalaban]

A list of system error messages, with some explanation about them: possible or most probable cause, relation with language constructs, with parts of the system (library, kernel)

here in this case :
- what is a signal ? How does the OS uses it?
- Why does the error message identifies the 'signal bit' if this can not in any way be related to some helpfull information?
I can readily understand a message that would tell me 'object/stucture not freed' so i am guessing system people that defined the error messages had some exploitation of that info in mind?

A signal is a standard way to deal with communication when doing "Inter Process Communication" (IPC) whatever system you are using. The idea is that when multiple processes has to communicate with each other but want to do it asynchronously they agree on a signal (in the literal non computer related meaning) that will indicate the other party has something for them. In computer a signal is a bit that can be raised (signal is on) or not (signal is absent), in AmigaOS each task owns a 32bit variable giving it 32 different possible signals to monitor. Note however that almost the 16 first have a fixed meaning by the system, while you, as a programmer, can use the upper 16 other bits for your communication.

Because AmigaOS is intrinsically multitask many parts of the system are using signals. For example the recommended way of handling user interaction with a window is to look at it's signal bit, when raised then it means you have messages waiting in the window's queue. The typical way of waiting a signal is to use exec/Wait() I suggest you read the appropriate autodoc, and without understanding the signal concept you'll hardly be able to build a truly multitasking GUI (IIRC you are working on gui4cli).

So it's enough for you to know that you can allocate a signal explicitly (for example to synchronize two processes) using AllocSignal() (in pre AOS4 style code) or AllocSysObject() (in AOS4 style code) but some system objects (especially in the GUI) are also implicitly allocating one if you do not provide them one (Window object for example).

AmigaOS never add resources tracking, however since AmigaOS 4 the system is able to alert that you some resources type haven't been freed (signals are one example) unfortunately it's not the case for many other system objects (Window for example aren't disposed automatically).

To finish, signals and messages are some of the more important basic concept in AmigaOS you'll better fully understand them before doing any serious development.

[salass00]

So it's enough for you to know that you can allocate a signal explicitly (for example to synchronize two processes) using AllocSignal() (in pre AOS4 style code) or AllocSysObject() (in AOS4 style code) but some system objects (especially in the GUI) are also implicitly allocating one if you do not provide them one (Window object for example).

I think you are confusing things here because signals are still allocated and freed with AllocSignal()/FreeSignal() on AmigaOS4.x. Maybe you are thinking of message ports which used to be created with CreateMsgPort() or CreatePort() (amiga.lib KS1.x compatibility function) and deleted with DeleteMsgPort() or DeletePort() depending on what function you used to create it, in AmigaOS4.x these are obsolete and you should use AllocSysObject()/FreeSysObject() instead.

AmigaOS never add resources tracking, however since AmigaOS 4 the system is able to alert that you some resources type haven't been freed (signals are one example) unfortunately it's not the case for many other system objects (Window for example aren't disposed automatically).

Just want to add that the reason that the shell specifically warns about unfreed signals is that when you run programs from the shell without using "run" the programs are being executed on the shell's process so any signals allocated will remain allocated for the shell process unless explicitly freed. In this case the shell is smart enough to detect that signals were allocated by the program and not freed and it warns about them (as it might be a sign of a bigger resource leak/problem in the program in question) and then I assume frees them.

[abalaban]

I think you are confusing things here because signals are still allocated and freed with AllocSignal()/FreeSignal() on AmigaOS4.x. Maybe you are thinking of message ports which used to be created with CreateMsgPort() or CreatePort() (amiga.lib KS1.x compatibility function) and deleted with DeleteMsgPort() or DeletePort() depending on what function you used to create it, in AmigaOS4.x these are obsolete and you should use AllocSysObject()/FreeSysObject() instead.

Thinking about it, it makes sense, of course you can AllocSysObject() a signal. I was effectively thinking of message ports.

Just want to add that the reason that the shell specifically warns about unfreed signals is that when you run programs from the shell without using "run" the programs are being executed on the shell's process so any signals allocated will remain allocated for the shell process unless explicitly freed. In this case the shell is smart enough to detect that signals were allocated by the program and not freed and it warns about them (as it might be a sign of a bigger resource leak/problem in the program in question) and then I assume frees them.

Interesting, however are you sure the shell will free the signal automatically? This can lead to even more problems than running out of signal bits, if you'd ask me.

[salass00]

Interesting, however are you sure the shell will free the signal automatically? This can lead to even more problems than running out of signal bits, if you'd ask me.

Easy enough to test. Just write in following type of program and run it a few times:

Code: Select all

#include <proto/exec.h>
#include <proto/dos.h>

int main() {
	int32 signal;
	signal = IExec->AllocSignal(-1);
	if (signal != -1) {
		IDOS->Printf("got signal: %ld\n", signal);
	} else {
		IDOS->Printf("didn't get a signal...\n");
	}
	return 0;
}

If it doesn't free the signals then it will return a different signal each time and eventually not return a signal at all.

I ran the test program several times and it always gets the same signal (31) so the shell definitely frees it automatically as I expected it would.

[abalaban]

@salass00

Thanks that's interesting to know.