<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
May be you could try to run your application with the valgrind tool
(<a class="moz-txt-link-freetext" href="http://valgrind.kde.org/">http://valgrind.kde.org/</a>), <br>
which may give you a clue in case you are doing something bad with the
memory.<br>
<br>
Cheers,<br>
Sergei<br>
<br>
Rene van 't Veen wrote:<br>
<blockquote type="cite"
cite="mid013d01c4804a$c6f6ba10$0411a8c0@starlight">
<pre wrap="">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" <a class="moz-txt-link-rfc2396E" href="mailto:kitzberger@nefkom.net"><kitzberger@nefkom.net></a>
To: "Rene van 't Veen" <a class="moz-txt-link-rfc2396E" href="mailto:rene@halotec.com"><rene@halotec.com></a>
Sent: Wednesday, August 11, 2004 10:49 PM
Subject: Re: [omniORB] SIGSEGV in omniFinalCleanup::~omniFinalCleanup
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->have
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">been added with registerNilCorbaObject(), because these references have
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->been
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">added from another dynamic shared object (of my own making) that is
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->unloaded
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">*before* omniORB4.so is unloaded. The problem doesn't occur if the code
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->that
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">does the corba calls is linked statically - but that would invalidate the
design, because the CORBA calling code is a plugin, loaded and unloaded
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->at
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:omniORB-list@omniorb-support.com">omniORB-list@omniorb-support.com</a>
<a class="moz-txt-link-freetext" href="http://www.omniorb-support.com/mailman/listinfo/omniorb-list">http://www.omniorb-support.com/mailman/listinfo/omniorb-list</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
omniORB-list mailing list
<a class="moz-txt-link-abbreviated" href="mailto:omniORB-list@omniorb-support.com">omniORB-list@omniorb-support.com</a>
<a class="moz-txt-link-freetext" href="http://www.omniorb-support.com/mailman/listinfo/omniorb-list">http://www.omniorb-support.com/mailman/listinfo/omniorb-list</a>
</pre>
</blockquote>
</body>
</html>