[omniORB] SIGSEGV in omniFinalCleanup::~omniFinalCleanup
Rene van 't Veen
rene at halotec.com
Thu Aug 12 12:00:06 BST 2004
Uhm, no. Apparently, omniFinalCleanup is accessing memory that isn't there
any more. To be a little more informative, here is a stack backtrace:
(gdb) info sharedlibrary
>From To Syms Read Shared Object Library
0x400215d0 0x40037b60 Yes
/home/rene/project/debug/liborb-support.so
0x400c23c0 0x4018f420 Yes /usr/local/lib/libomniORB4.so.0
0x40201260 0x40202e00 Yes /usr/local/lib/libomnithread.so.3
0x4020b100 0x40213150 Yes
/home/rene/project/debug/libplugin-base.so
0x4021f1c0 0x4022a050 Yes
/home/rene/project/debug/libshared-code.so
0x4023a360 0x40242de0 Yes /lib/libpthread.so.0
0x40262f80 0x403442a0 Yes /lib/libc.so.6
0x4036a780 0x40381340 Yes /lib/libm.so.6
0x403a1b50 0x403bd130 Yes /usr/lib/libstdc++-libc6.2-2.so.3
0x403d2d90 0x403d38a0 Yes /lib/libdl.so.2
0x400012c0 0x4000fdf0 Yes /lib/ld-linux.so.2
0x403dbd40 0x403e17c0 Yes /lib/libnss_files.so.2
0x40407470 0x4042f930 Yes
/home/rene/project/debug/libcpix4300mech.so
(gdb) c
Continuing.
/home/rene/project/debug/mechanicsd: handling one or more interrupts
/home/rene/project/debug/mechanicsd: SIGHUP/SIGTERM received: initiating
shutdown
... lots of output from application program snipped .. Suffice it to say
that all references that it has to objects
.. in other processes are dropped and that all object implementations that
it provided are dropped as well. Also,
.. the ORB has shutdown successfully and is deleted ...
Program received signal SIGSEGV, Segmentation fault.
0x400fdbb5 in _omniFinalCleanup::~_omniFinalCleanup () from
/usr/local/lib/libomniORB4.so.0
(gdb) info sharedlibrary
>From To Syms Read Shared Object Library
0x400215d0 0x40037b60 Yes
/home/rene/project/debug/liborb-support.so
0x400c23c0 0x4018f420 Yes /usr/local/lib/libomniORB4.so.0
0x40201260 0x40202e00 Yes /usr/local/lib/libomnithread.so.3
0x4020b100 0x40213150 Yes
/home/rene/project/debug/libplugin-base.so
0x4021f1c0 0x4022a050 Yes
/home/rene/project/debug/libshared-code.so
0x4023a360 0x40242de0 Yes /lib/libpthread.so.0
0x40262f80 0x403442a0 Yes /lib/libc.so.6
0x4036a780 0x40381340 Yes /lib/libm.so.6
0x403a1b50 0x403bd130 Yes /usr/lib/libstdc++-libc6.2-2.so.3
0x403d2d90 0x403d38a0 Yes /lib/libdl.so.2
0x400012c0 0x4000fdf0 Yes /lib/ld-linux.so.2
0x403dbd40 0x403e17c0 Yes /lib/libnss_files.so.2
0x403e41c8 0x403e8898 Yes /lib/libgcc_s.so.1
(gdb) info stack
#0 0x400fdbb5 in _omniFinalCleanup::~_omniFinalCleanup () from
/usr/local/lib/libomniORB4.so.0
#1 0x4018edf8 in __static_initialization_and_destruction_0 () from
/usr/local/lib/libomniORB4.so.0
#2 0x4018ee5e in global destructors keyed to
_omni_unixActive_should_be_linked_but_is_not_ () from
/usr/local/lib/libomniORB4.so.0
#3 0x400c2443 in __do_global_dtors_aux () from
/usr/local/lib/libomniORB4.so.0
#4 0x4018f439 in _fini () from /usr/local/lib/libomniORB4.so.0
#5 0x4000a136 in _dl_fini () from /lib/ld-linux.so.2
#6 0x40275e53 in exit () from /lib/libc.so.6
#7 0x0805d814 in main (argc=2, argv=0xbffffb04) at main.cpp:47
The problem seems to be that '/home/rene/project/debug/libcpix4300mech.so'
is no longer loaded. This shared object is loaded into the process via a
call to dlopen() (LoadLibrary in MS-Windows) and that the ORB has somehow
retained references to the additional address space there. Apparently,
exit() unloads all loaded dynamic shared libraries, but unloads
'/home/rene/project/debug/libcpix4300mech.so' first because it isn't linked
in as such. When I do link it in (I have to create another program to do
that and it doesn't behave quite as similarly as my main program), then I do
have a number of nil object references reported by omniFinalCleanup:
omniORB: ObjRef() -- deleted.
omniORB: No more references to the ORB -- deleted.
omniORB: Final clean-up
omniORB: Deleted 14 nil object references and 0 other tracked objects.
omniORB: Final clean-up completed.
So:
- either I must be doing something wrong in my application code that these
nil object references still exist. (I use lots of xxx_var smart pointers
there and all accesses are locally or instance scoped (for class members)
with exception handling)
- or this is a bug - in a way - I'm not too sure
If needs be I can hack my way around this my building a modified version of
omniORB:
- not removing the list of nil object references in ~omniFinalCleanup, just
reporting its size.
- removing the list of nil object references just after the ORB has shutdown
*and* deleted
But then I wouldn't really know what I'm doing
Regards,
Rene van 't Veen
----- Original Message -----
From: "Eberhard Kitzberger" <kitzberger at nefkom.net>
To: "Rene van 't Veen" <rene at halotec.com>
Sent: Wednesday, August 11, 2004 10:49 PM
Subject: Re: [omniORB] SIGSEGV in omniFinalCleanup::~omniFinalCleanup
> Hello,
> don't know if it helps, but I had a similar SIGSEV in omniFinalCleanup
> when code was not fully compiled with C++ exception handling. In my
> case, the omniOrb throw an exception that was correctly handled by
> omniOrb but when it tried to return into the calling routine there was
> no excption handling in the code to catch and program cored.
> Regards
> Eberhard
>
> Rene van 't Veen schrieb:
>
> >Hello,
> >
> >I've got a problem in that I keep getting a SIGSEGV in
> >omniFinalCleanup::~omniFinalCleanup (Linux, 2.4.18), which is called when
> >the dynamic shared object (omniORB4.so) unloads during exit() processing.
> >The problem appears to revolve arround cleaning up the references that
have
> >been added with registerNilCorbaObject(), because these references have
been
> >added from another dynamic shared object (of my own making) that is
unloaded
> >*before* omniORB4.so is unloaded. The problem doesn't occur if the code
that
> >does the corba calls is linked statically - but that would invalidate the
> >design, because the CORBA calling code is a plugin, loaded and unloaded
at
> >runtime.
> >
> >Anyone able to shed any light on this subject? Is there a method through
> >which I can avoid the segmentation fault?
> >
> >Regards,
> >
> >RvtV
> >
> >
> >_______________________________________________
> >omniORB-list mailing list
> >omniORB-list at omniorb-support.com
> >http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> >
> >
> >
> >
>
>
>
More information about the omniORB-list
mailing list