[omniORB] SIGSEGV in omniFinalCleanup::~omniFinalCleanup
Serguei Kolos
Serguei.Kolos at cern.ch
Thu Aug 12 12:12:38 BST 2004
May be you could try to run your application with the valgrind tool
(http://valgrind.kde.org/),
which may give you a clue in case you are doing something bad with the
memory.
Cheers,
Sergei
Rene van 't Veen wrote:
>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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>_______________________________________________
>omniORB-list mailing list
>omniORB-list at omniorb-support.com
>http://www.omniorb-support.com/mailman/listinfo/omniorb-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20040812/6766524f/attachment-0001.htm
More information about the omniORB-list
mailing list