[omniORB] Assertion failed

Sai-Lai Lo S.Lo@uk.research.att.com
09 Aug 1999 11:36:44 +0100


Helmut,

> #### Communication failure. Connection closed.
> ../logIOstream.cc(8026):160
> ../logIOstream.cc(8026):102
> tcpSocketMT Worker thread: exits.
> ../logIOstream.cc(8026):160
> ../posix.cc(8026):727
> ../posix.cc(8026):756
> ../posix.cc(8026):115
> ../posix.cc(8026):122
> ../strand.cc(8026):247
> ../posix.cc(8026):115
> ../strand.cc(8026):133
> ../strand.cc(8026):146
> ../strand.cc(8026):395
> ../tcpSocketMTfactory.cc(8026):680
> ../logIOstream.cc(8026):102
> tcpSocketStrand::~Strand() close socket no. 16
> ../logIOstream.cc(8026):118
> ../logIOstream.cc(8026):102
> ../logIOstream.cc(8026):160
> ../relStream.cc(8026):71
> ../strand.cc(8026):97
> ../strand.cc(8026):146
> ../posix.cc(8026):147
> ../posix.cc(8026):147
> ../posix.cc(8026):122
> ../posix.cc(8026):502
> ../posix.cc(8026):108

This trace does look normal to me. (With all the trace info you put in, the
line numbers have been offset by some amount. I can only guess at the flow
of execution but there is nothing out of the ordinary).

Let me explain what is happening there. The worker thread try loop catch a
COMM_FAILURE. It exits. This call returns to omni_thread_wrapper.
omni_thread_wrapper calls delete on the omnithread object
(tcpSocketWorker). The dtor of tcpSocketWorker is executed. The dtor of the
private member of tcpSockerWorker: pd_sync is executed. This release the
strand the tcpSocketWorker is using. It also detects that the strand has
been set to be dying (again normal). So it close the socket. In the end,
everything got clean up nicely.

There is just not enough information to work on. At the moment, I'm still
not convinced your crash is caused by a problem in the runtime.

To progress any further, how about running your appl. under gdb and show me
the stack trace of all the threads when it crashes. The core dump on linux is
of no use because it does not contain sufficent MT info.

I presume Suse ships with a gdb version and glibc runtime patched with the
MT debugging support. If not, you may consider using redhat 5.2 +
egcs-1.1.2. This combination is better because this is the version we are
using. (With redhat 5.2, please build egcs-1.1.2 yourself with the
--enable-threads option, don`t just grab some RPMs from some random
places.)

Sai-Lai






-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND