Discussion:
[omniORB] Odd behavior on linux with NPTL
Arne Pajunen
2006-11-10 21:09:05 UTC
Permalink
Hi,

I'm getting really odd behavior on Debian i386 testing using NPTL
pthreads. I'm using OmniORB 4.0.7.

I start a separate thread (pthreads, behaves the same if i use
omnithreads for it, or call omni_thread::create_dummy()) which just runs
orb->run();

when the applications terminates with exit(0); the destructor of
omni_condition throws a exception

the call stack from the aborting thread

Thread 1 (Thread -1478687040 (LWP 2093)):
#0 0xa7dfd947 in raise () from /lib/tls/libc.so.6
#1 0xa7dff0c9 in abort () from /lib/tls/libc.so.6
#2 0x08395917 in __cxxabiv1::__terminate ()
#3 0x08395954 in std::terminate ()
#4 0x08395ac6 in __cxa_throw ()
#5 0x08357479 in omni_condition::~omni_condition ()
#6 0xa7e004f0 in exit () from /lib/tls/libc.so.6
#7 0x080695bf in main (argc=2, argv=0xafa79344) at ot.cxx:789

The attached file contains full output of: thread apply all bt

Anyways it looks clear that in the call to exit the destructor is
called, and it throws because there are still threads waiting on the
condition. Anything I'm doing wrong here ? This code used to work with mico.

I've seen no crashes with a simple workaround of skipping starting the
thread and running orb->run();

All options are at default except verifyObjectExistsAndType = 0

Any ideas about whats causing the crash appreciated.

Best regards,
--
Arne Pajunen
Software Engineer
OpenTTCN Oy, Test and Test Control Components for Test System Vendors
Web: http://www.openttcn.com
Email: ***@openttcn.fi
-------------- next part --------------
Thread 4 (Thread -1495467088 (LWP 2098)):
#0 0xa7f0fe62 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/tls/libpthread.so.0
#1 0x08357515 in omni_condition::timedwait ()
#2 0x083124c1 in omni::Scavenger::execute ()
#3 0x082d3d7f in omniAsyncWorker::real_run ()
#4 0x082d3c47 in omniAsyncWorker::run ()
#5 0x08357b5a in omni_thread_wrapper ()
#6 0xa7f0d0bd in start_thread () from /lib/tls/libpthread.so.0
#7 0xa7ea092e in clone () from /lib/tls/libc.so.6

Thread 3 (Thread -1487078480 (LWP 2097)):
#0 0xa7f0fc01 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/tls/libpthread.so.0
#1 0x0835749d in omni_condition::wait ()
#2 0x082bcd7c in omniOrbORB::run ()
#3 0x0814c1c2 in OpenTTCN::ISL::Initializer_runHelper_Internal ()
#4 0xa7f0d0bd in start_thread () from /lib/tls/libpthread.so.0
#5 0xa7ea092e in clone () from /lib/tls/libc.so.6

Thread 2 (Thread -1478689872 (LWP 2096)):
#0 0xa7e995e7 in select () from /lib/tls/libc.so.6
#1 0x0832f91b in omni::SocketCollection::Select ()
#2 0x083512b3 in omni::tcpEndpoint::AcceptAndMonitor ()
#3 0x0831ae01 in omni::giopRendezvouser::execute ()
#4 0x082d3d7f in omniAsyncWorker::real_run ()
#5 0x082d3c47 in omniAsyncWorker::run ()
#6 0x08357b5a in omni_thread_wrapper ()
#7 0xa7f0d0bd in start_thread () from /lib/tls/libpthread.so.0
#8 0xa7ea092e in clone () from /lib/tls/libc.so.6

Thread 1 (Thread -1478687040 (LWP 2093)):
#0 0xa7dfd947 in raise () from /lib/tls/libc.so.6
#1 0xa7dff0c9 in abort () from /lib/tls/libc.so.6
#2 0x08395917 in __cxxabiv1::__terminate ()
#3 0x08395954 in std::terminate ()
#4 0x08395ac6 in __cxa_throw ()
#5 0x08357479 in omni_condition::~omni_condition ()
#6 0xa7e004f0 in exit () from /lib/tls/libc.so.6
#7 0x080695bf in main (argc=2, argv=0xafa79344) at ot.cxx:789
Duncan Grisby
2006-11-16 16:07:38 UTC
Permalink
Post by Arne Pajunen
I start a separate thread (pthreads, behaves the same if i use
omnithreads for it, or call omni_thread::create_dummy()) which just
runs orb->run();
There's never any need to do that. Unless you call it from the main
thread, orb->run() just blocks doing nothing. omniORB uses its own
threads to dispatch incoming calls, so you don't need to call run().
Post by Arne Pajunen
when the applications terminates with exit(0); the destructor of
omni_condition throws a exception
That's just because the thread doing run() is blocked on the condition
variable, and exiting deletes it. You should either not call orb->run(),
or call orb->destroy() to unblock any threads in run().

Cheers,

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --
Loading...