Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
61 user(s) are online (49 user(s) are browsing Forums)

Members: 0
Guests: 61

more...
Support us!
Recent OS4 Files
OS4Depot.net





unfreed signals......again
Just popping in
Joined:
2015/9/28 23:42
From Bettendorf, IA, USA
Posts: 169
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?

   Report Go to top

Re: unfreed signals......again
Home away from home
Joined:
2006/12/4 23:15
Posts: 2073
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.

_________________
Blender For OS4.x : Blues : Walker Broad
   Report Go to top

Re: unfreed signals......again
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 2725
@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 9:28:42
Edited by LiveForIt on 2019/5/1 9:57:18
Edited by LiveForIt on 2019/5/1 10:01:35
Edited by LiveForIt on 2019/5/1 10:02:46
Edited by LiveForIt on 2019/5/2 20:54:05
Edited by LiveForIt on 2019/5/2 20:54:52
_________________
(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
   Report Go to top

Re: unfreed signals......again
Home away from home
Joined:
2006/12/4 23:15
Posts: 2073
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!






_________________
Blender For OS4.x : Blues : Walker Broad
   Report Go to top

Re: unfreed signals......again
Just popping in
Joined:
2015/9/28 23:42
From Bettendorf, IA, USA
Posts: 169
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
   Report Go to top

Re: unfreed signals......again
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 2725
@broadblues

sorry remembered wrong this code:

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


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 restoredn");
    }
#endif

_________________
(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
   Report Go to top

Re: unfreed signals......again
Just can't stay away
Joined:
2006/11/30 11:30
From Finland
Posts: 1648
@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().

   Report Go to top

Re: unfreed signals......again
Not too shy to talk
Joined:
2008/5/2 12:14
From Sweden
Posts: 499
@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++
   Report Go to top

Re: unfreed signals......again
Just popping in
Joined:
2015/9/28 23:42
From Bettendorf, IA, USA
Posts: 169
@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
   Report Go to top

Re: unfreed signals......again
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 2725
@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.
   Report Go to top

Re: unfreed signals......again
Just popping in
Joined:
2015/9/28 23:42
From Bettendorf, IA, USA
Posts: 169
@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?

   Report Go to top

Re: unfreed signals......again
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 2725
@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 21:01:36
_________________
(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
   Report Go to top

Re: unfreed signals......again
Just popping in
Joined:
2015/9/28 23:42
From Bettendorf, IA, USA
Posts: 169
@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 15:52:05
   Report Go to top

Re: unfreed signals......again
Home away from home
Joined:
2006/12/4 23:15
Posts: 2073
@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.



_________________
Blender For OS4.x : Blues : Walker Broad
   Report Go to top





[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project