Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
108 user(s) are online (70 user(s) are browsing Forums)

Members: 1
Guests: 107

smf, more...

Headlines

 
  Register To Post  

unfreed signals......again
Just popping in
Just popping in


See User information
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?

Go to top
Re: unfreed signals......again
Home away from home
Home away from home


See User information
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.

Go to top
Re: unfreed signals......again
Home away from home
Home away from home


See User information
@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.


Edited by LiveForIt on 2019/5/1 10:28:42
Edited by LiveForIt on 2019/5/1 10:57:18
Edited by LiveForIt on 2019/5/1 11:01:35
Edited by LiveForIt on 2019/5/1 11:02:46
Edited by LiveForIt on 2019/5/2 21:54:05
Edited by LiveForIt on 2019/5/2 21:54:52
(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: unfreed signals......again
Home away from home
Home away from home


See User information
Quote:


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

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


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:

For libc programs there is sigaction(?) command.


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

Quote:

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.


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!






Go to top
Re: unfreed signals......again
Just popping in
Just popping in


See User information
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.

Workbench Explorer - A better way to browse drawers
Go to top
Re: unfreed signals......again
Home away from home
Home away from home


See User information
@broadblues

sorry remembered wrong this code:

ULONG exceptCode struct ExecBase *SysBaseULONG signalsULONG exceptData)
{
    if (
exceptData SIGBREAKF_CTRL_C)
    {
        
SetSignal0LSIGBREAKF_CTRL_C);
        
Printf("CTRL C\n");
    }
}


init exception.

#ifdef __amigaos__
    
struct Task *me;
    
APTR oldException;
    
ULONG oldSigExcept;

    
me FindTask(NULL);    // don't need forbid, not looking for name.
    
oldException me -> tc_ExceptCode;
    
me -> tc_ExceptCode = (APTRexceptCode;

    
oldSigExcept SetExcept(0,);
    
SetExceptSIGBREAKF_CTRL_CSIGBREAKF_CTRL_C );
#endif


before exit

#ifdef __amigaos__
    
if ( me )
    {
        
SetExceptoldSigExcept,oldSigExcept SIGBREAKF_CTRL_C );
        
me -> tc_ExceptCode oldException;
        
Printf("Old exception handler restored\n");
    }
#endif

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: unfreed signals......again
Just can't stay away
Just can't stay away


See User information
@LiveForIt

Quote:

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 want to have a cleanup function called when exit() is called from the main process then you are better off using atexit().

Go to top
Re: unfreed signals......again
Quite a regular
Quite a regular


See User information
@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

Software developer for Amiga OS3 and OS4.
Develops for OnyxSoft and the Amiga using E and C and occasionally C++
Go to top
Re: unfreed signals......again
Just popping in
Just popping in


See User information
@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.

Workbench Explorer - A better way to browse drawers
Go to top
Re: unfreed signals......again
Home away from home
Home away from home


See User information
@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);

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: unfreed signals......again
Just popping in
Just popping in


See User information
@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?

Go to top
Re: unfreed signals......again
Home away from home
Home away from home


See User information
@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"



Edited by LiveForIt on 2019/5/4 22:01:36
(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: unfreed signals......again
Just popping in
Just popping in


See User information
@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.


Edited by mritter0 on 2019/5/5 16:52:05
Go to top
Re: unfreed signals......again
Home away from home
Home away from home


See User information
@mritter0


Quote:

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


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

Quote:

Even necessary?


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.



Go to top

  Register To Post

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project