Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

application crash on exit(0)

77 views
Skip to first unread message

Anis

unread,
May 30, 2004, 12:07:35 PM5/30/04
to
Hello,

I am getting an application crash when exit(0) is called after forking to
make
a daemon process.


The program uses standard method for daemonizing and uses a bunch of shared
libraries.

// Dissociate from the terminal
if( ( pid = fork() ) != 0 )
{
// Parent Process
if( -1 == pid )
{
// Serious problem , lets bail out

raise(SIGTRAP);
}

// Terminate Parent
exit( 0 );
}
// Become Session Leader
// The child is still the process the group leader.
setsid();

// Fork again so that the child is not the process group leader.
if( ( pid = fork() ) != 0 )
{
if( -1 == pid )
{

raise(SIGTRAP);

// Terminate Parent
exit( 0 );
}

But when, the parent process calls exit( 0 ), I have occasional (not always)
crashes dumping core. The code is running
on ppc/linux (Linux version 2.4.18-rc4 / gcc version 3.2.3 20030401 )


#0 0x0f8c387c in __FRAME_END__ () from /home/bt42/export/ppc/lib/libsv.so
#1 0x0f8b0004 in __static_initialization_and_destruction_0(int, int)
(__initialize_p=1207960804, __priority=263335744)
at /home/bt42/export/ppc/fips/include/evenmgt.H:594
#2 0x0f8b0178 in _GLOBAL__D_g_svCompBufferSize () at
/home/bt42/export/ppc/include/evenmgt.H:594
#3 0x0f875200 in __do_global_dtors_aux () from
/home/bt42/export/ppc/lib/libsv.so
#4 0x0f8b08c0 in _fini () from /home/bt42/export/ppc/lib/libsv.so
#5 0x3000bc00 in _dl_fini () at dl-fini.c:169
#6 0x0fb22c78 in exit (status=0) at exit.c:58
#7 0x10004c44 in survDaemonize () at /home/bt42/surv/clienthandler.C:508
#8 0x1000475c in main () at /home/bt42/surv/clienthandler.C:208


I googled for similar problem and I did notice that was due to the runtime
linker sometimes running the _fini sections of dynamic libraries in the
wrong order at exit.

Can someone please help me debug this problem or if this is a known problem,
can I get a confirmation of that? I highly appreciate any
help on this issue..
If any other information is required, I will be more than happy to provide.

Thanks in advance and REgards
Anis

Kasper Dupont

unread,
May 30, 2004, 12:21:17 PM5/30/04
to
Anis wrote:
>
> Hello,
>
> I am getting an application crash when exit(0) is called after forking to
> make
> a daemon process.

Probably memory corruption is happening somewhere
earlier in your program.
http://www.daimi.au.dk/~kasperd/comp.os.linux.development.faq.html#SIGSEGV

>
> I googled for similar problem and I did notice that was due to the runtime
> linker sometimes running the _fini sections of dynamic libraries in the
> wrong order at exit.

What kind of libraries do you use? What do they need
to do on exit?

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use kas...@kd.lir.dk and ab...@kd.lir.dk
I'd rather be a hammer than a nail.

Johan Hendriks

unread,
Jun 9, 2004, 2:55:56 AM6/9/04
to

Your program crashes in the destructor of a a global object

To prevent this you can use _exit. This will not execute global destructors.

You should examine your code to see why the destructor crashes.


Kasper Dupont

unread,
Jun 11, 2004, 12:48:53 PM6/11/04
to
Johan Hendriks wrote:
>
> Your program crashes in the destructor of a a global object
>
> To prevent this you can use _exit. This will not execute global destructors.

In some cases using _exit can be a good idea. For example
if you create a new process using fork, you probably only
want one of them to actually call the destructors. In the
very often seen case of fork followed by execve, the
destructors will not be called in case of a successfull
execve call. So in case of a failing execve I usually use
the _exit call. If you are forking yourself into the
background (like for example the daemon call does), you
should also use _exit in the parent process.

But calling the destructor in both processes should not
cause a segmentation fault. In that case using _exit to
avoid the segmentation fault is a very bad idea. Instead
you should find the real bug.

>
> You should examine your code to see why the destructor crashes.

Yes, I agree with that.

0 new messages