[omniORB] Thread error?

[Jo Skjermo]

OBS! sorry bouth that, here is the stack trace :

(gdb)where
#0  replace (this=0xdee01998, pos=0, n1=0, s=0x806f049 "pid", n2=3) at ./sinst.cc:411
#1  0xdf6668e2 in __as__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0PCc () at ./sinst.cc:181
#2  0x8060ea1 in SMSReceive::getMessage ()
#3  0x8063913 in getMessage (this=0x8095b90, username=0x8095930 "jule", password=0x8095900 "nisse", provider_ID=0x8097bc0 "bobsWASP") at smsapi.C:24
#4  0x805da11 in _impl_api::_dispatch ()
#5  0xdfa2f9b1 in omniOrbPOA::dispatch () from /usr/local/omni/lib/x86_sosV_5.5/libomniORB3.so.0
#6  0xdfa23ed7 in omniLocalIdentity::dispatch () from /usr/local/omni/lib/x86_sosV_5.5/libomniORB3.so.0
#7  0xdfa58f12 in GIOP_S::HandleRequest () from /usr/local/omni/lib/x86_sosV_5.5/libomniORB3.so.0
#8  0xdfa58696 in GIOP_S::dispatcher () from /usr/local/omni/lib/x86_sosV_5.5/libomniORB3.so.0
#9  0xdfa7b4bd in tcpSocketWorker::_realRun () from /usr/local/omni/lib/x86_sosV_5.5/libomniORB3.so.0
#10 0xdfa9570d in omniORB::giopServerThreadWrapper::run () from /usr/local/omni/lib/x86_sosV_5.5/libomniORB3.so.0
#11 0xdfa7b43b in tcpSocketWorker::run () from /usr/local/omni/lib/x86_sosV_5.5/libomniORB3.so.0
#12 0xdf7b37ef in omni_thread_wrapper () from /usr/local/omni/lib/x86_sosV_5.5/libomnithread.so.2

Also, yesterday we compiled things on Linux (i586) box instead, and
everything seemed to work great there (at least we sendt a couple of
mill. messages before we grew tired:)

BUT, then we found a very strange problem. When we run the server with
the -ORBtraceLevel flagg sett, the server froze after outputting the IOR,
and wouldnt take ANY connections.

That is, normal output of -ORBtraceLevel 25 should be something like:
...
'IOR:010000000c00000049444c3a6170693a312e300001000000000000002a000000010100000d0000003139322e3136382e312e35310020fb810e000000fec734d43a000005e50000000000'
omniORB: strand Ripper: start.
omniORB: scavenger : start.
omniORB: tcpSocketMTfactory Rendezvouser: start.
omniORB: tcpSocketMTfactory Rendezvouser: block on accept()

But on Linux we only get :
omniORB: strand Ripper: start.
omniORB: gateKeeper is tcpwrapGK 1.0 - based on tcp_wrappers_7.6
omniORB: strand Rope::incrRefCount: old value = 0
omniORB: Creating ref to remote: key<0x494e4954>
 target id      : IDL:omg.org/CORBA/Object:1.0
 most derived id: omg.org/CORBA/InitialReferences:1.0
omniORB: Initialising omniDynamic library.
omniORB: Initialising incoming rope factories.
omniORB: strand Rope::incrRefCount: old value = 0
omniORB: Starting incoming rope factories.
omniORB: scavenger : start.
omniORB: strand Rope::incrRefCount: old value = 0
omniORB: Creating ref to remote: root<0>
 target id      : IDL:omg.org/CORBA/Object:1.0
 most derived id: IDL:db:1.0
omniORB: strand Rope::incrRefCount: old value = 1
omniORB: Creating ref to remote: root<0>
 target id      : IDL:omg.org/CORBA/Object:1.0
 most derived id: IDL:db:1.0
omniORB: Activating: root<0>
omniORB: Creating ref to local: root<0>
 target id      : IDL:api:1.0
 most derived id: IDL:api:1.0
'IOR:010000000c00000049444c3a6170693a312e300001000000000000002a000000010100000d0000003139322e3136382e312e35340065d8070e000000feb751d43a000041910000000000'

THEN NOTHING????

Any ideas why things freezes when using -ORBtraceLevel xx at Linux???

MVH
Jo Skjermo
joskj@idi.ntnu.no


On Tue, 10 Apr 2001, Duncan Grisby wrote:

> On Friday 6 April, Jo Skjermo wrote:
>
> > I got somthing here that i think is a thread problem
> > (in Solaris Intel, 2.8 , omniorb 3.0.2).
>
> > Using GDB on the core i got the following :
> >
> > Core was generated by `smsapi
> > IOR:010000000b00000049444c3a64623a312e30000001000000000000002a0000000101'.
>
> [...]
> > #0  replace (this=0xded00980, pos=0, n1=0, s=0x8071ac6 "get_SMS", n2=7) at  ./sinst.cc:411
> > 411     ./sinst.cc: No such file or directory.
>
> It dies in your code, so it's most likely that that is where the
> problem lays. Just knowing which function it dies in isn't very
> helpful -- a stack trace might give more information. Type "bt" (or
> "where") at the gdb prompt.
>
> Cheers,
>
> Duncan.
>
> --
>  -- Duncan Grisby  \  Research Engineer  --
>   -- AT&T Laboratories Cambridge          --
>    -- http://www.uk.research.att.com/~dpg1 --
>