Help. Program coredumps with SIGILL after exit (0) is called

[anismo]

Hi,

I have an application that uses a couple of shared libraries and this
application forks to become a daemon. But when the parent after the
fork
calls exit(0), I am getting a coredump . Upon analyzing the core
in gdb, I see that the SIGILL seems to occur after _fini of a
sharedlibrary... Also, from the backtrace I can see that some
static data is getting deallocated and somehow the code seems
to get into the .plt section..

Here is the gdb back trace of the core file.

#0 0x0f8c387c in __FRAME_END__ () from
/home/yr14/prog12/export/ppc/lib/libsv.so
#1 0x0f8b0004 in __static_initialization_and_destruction_0(int, int)
(__initialize_p=1207960804, __priority=263335744)
#2 0x0f8b0178 in _GLOBAL__D_g_svpdCompBufferSize () at
/home/yr14/prog12/evenmgt.H:594
#3 0x0f875200 in __do_global_dtors_aux () from
/home/yr14/prog12/export/ppc/lib/libsv.so
#4 0x0f8b08c0 in _fini () from
/home/yr14/prog12/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
..
..

This seems to occur very rarely (almost like some sort of memory
corruption).
Here are my assumptions
When the parent exits, it calls the _fini of the every
shared library.
if there are any problem in the global data allocation,
will this result in the kind of problem I see here?

I seem to see this only on applications that have its child continue
execution while the parent exits out.

Any help with regard to what I should be looking at the find a
resolution
of this problem will be highly appreciated. My understanding of the
linker/loader process is not very good, so even if it sounds trivial
please
let me know.

This code was runing in a ppc environment running linux. I would be
more
than happy to provide any more information on this.

Thanks in advance and Regards
Anis

[Artie Gold]

an****@yahoo.com wrote:

Hi,

I have an application that uses a couple of shared libraries and this
application forks to become a daemon. But when the parent after the
fork
calls exit(0), I am getting a coredump . Upon analyzing the core
in gdb, I see that the SIGILL seems to occur after _fini of a
sharedlibrary... Also, from the backtrace I can see that some
static data is getting deallocated and somehow the code seems
to get into the .plt section..

Here is the gdb back trace of the core file.

#0 0x0f8c387c in __FRAME_END__ () from
/home/yr14/prog12/export/ppc/lib/libsv.so
#1 0x0f8b0004 in __static_initialization_and_destruction_0(int, int)
(__initialize_p=1207960804, __priority=263335744)
#2 0x0f8b0178 in _GLOBAL__D_g_svpdCompBufferSize () at
/home/yr14/prog12/evenmgt.H:594
#3 0x0f875200 in __do_global_dtors_aux () from
/home/yr14/prog12/export/ppc/lib/libsv.so
#4 0x0f8b08c0 in _fini () from
/home/yr14/prog12/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
.
.

This seems to occur very rarely (almost like some sort of memory
corruption).
Here are my assumptions
When the parent exits, it calls the _fini of the every
shared library.
if there are any problem in the global data allocation,
will this result in the kind of problem I see here?

I seem to see this only on applications that have its child continue
execution while the parent exits out.

Any help with regard to what I should be looking at the find a
resolution
of this problem will be highly appreciated. My understanding of the
linker/loader process is not very good, so even if it sounds trivial
please
let me know.

This code was runing in a ppc environment running linux. I would be
more
than happy to provide any more information on this.

Thanks in advance and Regards
Anis

Though most of what you describe above is platform specific -- hence off
topic in news:comp.lang.c -- this kind of error is most frequently
caused by overruning a static buffer.

Past that, I can only recommend posting in a more appropriate forum such
as news:comp.unix.programmer or news:comp.os.linux.development.apps.

HTH,
--ag

--
Artie Gold -- Austin, Texas