unfreed signals......again

I am getting this error message when quit my program:

command 'struct' returned with unfreed signals 18000000!

I have seen this before on the forums with a different value. I have tracked down every port and signal that I use, all seem good.

Is there any special meaning to this value?

Nothing special except that it shows you have two users signals set bit 31 and 30

Most often you get this kind of thjing when quitting with CTRL_C and the prgram doesn't exot via the normal exit path perhaps because the c library ctrl-c handler was still in place.

@mritter0

It as case of badly coded program.

Program open a resource or single, and does not free that resource or single. (resulting in file locks getting stuck, so you can't open or delete a file, resulting in program not finding free signals, or not being able to allocate memory, because there no free memory. and can also result in system freeze in the worst case.)

Some programs ported from Linux has the "exit(1)" command, this result into quit at that point the command is, but wont run the shutdown procedure. (you can add atexit(...) to fix this)

(Linux has resource tracking, so it can clean up the mess. AmigaOS does NOT have resource tracking so you as programer most clean up the mess, AmigaOS has no idea what resources your program has used (disk, memory, signals, graphics, and lock's), and does not know how to clean up.)

And Then there is the CTRL+C, this also stops the program on clib pirntf's and stuff like that. so you can have program that quits unexpected places in the code, again not freeing its resources.

There are ways you can improve your program, by adding custom signal handler, exec has SetExcept(…)

(just make sure resource the original one, before quitting, or else you modify the handler used by shell. And you get nasty crashes).

For libc programs there is sigaction(…) command.

In addition AmigaOS has possibility of execute a on death routine when program quits, this one is normally added to process if create a process from your program, but I think you can hack the running process as well, to add a on death routine.

If you have C++ program, you can also write object.

Deconstruct method is automatically called on all static objects.

Example:

class OsResources
{
Public:
OsResources:: OsResources(); // init…
OsResources::~ OsResources(); // deconstruction
bool OsResources::success();
};

OsResources myResources;

int main(…)
{
if(myResources.success())
{

}
};

Edit: added/fxied few things from the comments below.

Quote:

IExec->SetSignal() has nothing todo with c library signal handlers.


The function you need it signal()

in this context it;s simplest to set it to SIG_IGN (ignore the signal).

signal(SIG_INT,SIG_IGN);

You do not need to set this back again at program exit because the shell is 1. a separate prgram 2. not using newlib or clib2 anayway.

Quote:

No we don't hae that, newlib and clib2 only support signal() as far as I'm aware.

Quote:

Seriously don't do that! The program is likely running on the same process as the shell that started it so if you managed you change the process death function it wouldn't get called till you close the shell after your program has been unloaded, so big crash!

It took me several hours of testing but I figured it out.

IApplication->RegisterApplication() was being done twice. So the original "signal" was lost when done the second time.

@broadblues

sorry remembered wrong this code:



init exception.



before exit

@LiveForIt

Quote:

If you want to have a cleanup function called when exit() is called from the main process then you are better off using atexit().

@mritter0

Good catch!
So while the others are babbling away, you had to do the work yourself. Tends to be that way

I was going to suggest that you might have forgotten to close a MsgPort, or a timer device or something. But you found it. Signals are hiding in wierd places

@Deniil

I did have a port left open before. It had a different value, 02000000. So I was hoping this new value had some other meaning to help track it down.

@mritter0

so guess you can find where there signal is allocated, by doing some printf's.

me = FindTask(NULL);

printf("%s:%d,allocated signals %08x\n",__FUNCTION__,__LINE__, me -> tc_SigAlloc);

@LiveForIt

I put a line after everything is up and running, result:

MyProgram:208,allocated signals fff8ffff


Then again just before quitting, result:

MyProgram:526,allocated signals 0000ffff


How many signals are allocated?

@mritter0


Well hex $0000FFFF is ‭%1111111111111111‬ binary so that's 16 signals that are allocated.

this low bits are preallocated signals like CTRL+C, CTRL+D and so on.

Max number of singal's are 32, you have ‭used 21 signals, and have 7 left. If your opening lots of windows, it is possible for windows to share userport "WA_UserPort"

@LiveForIt

That seems high. One window, I count only 6 signal bits being used (that I am allocating), probably drop to 4 in the coming weeks. So I guess the preallocated bits are "quite a few".

I went through this problem with Workbench Explorer. I was told you have 16 signals to use, which I maxed out. I had to disable one so could open more dialogue windows. Colin Wenzel (?) told me they are working hard to get to 32 signals since this is a common problem with modern programs.


signal(SIGINT,SIG_IGN);
What does this ignore? Even necessary?


EDIT:

After searching for something else related to this: The user gets access to 16 bits, so of the 32 total, then yes, I am using 21 total; 5 for my program.

@mritter0


Quote:

If sets the C library signal handler to Ignore the SIGINT signal (that's essentially posix speak for SIGBREAKF_CTRL_C)

Quote:

If you are using printf() and other stdio functions but handling CTRL_C yourself in the main loop (or where ever) then yes it is, as it stops your program breaking out unexpectedly, if you are using exclusively dos.library IO or have no IO at al then it's not neccessasry but is harnless.