[omniORB] Assertion failed
Sai-Lai Lo
S.Lo@uk.research.att.com
29 Jul 1999 17:11:48 +0100
Helmut,
The trace message you are seeing tells you that the server thread
(tcpSocketMT Worker) detects that the socket it is blocking on has been
closed by the remote end. I think this is because your client process exits
and so the socket was closed. Seeing the socket closedown, tcpSocketMT
Worker throws a COMM_FAILURE exception which is caught in the outer most
try loop of the thread which causes the thread to exit and the dtor on the
strand called.
This is all normal behaviour.
I suggest you upgrade to egcs-1.1.2 (remember the --enable-threads option)
and try again. It is one variable that I would like to remove.
If the problem still persists, you really have to do some digging in your
code to try to isolate a test case for me to work on. (Sometimes, it may
just be a stack overflow that is causing the problem. You happen to define
a huge array as an IDL operation argument for instance.)
Sai-Lai
>>>>> Helmut Swaczinna writes:
> I've disabled the scavengers, but the problem still remains. It is
> always the same: The server process crashes *after* a method invocation,
> not during method execution. The client gets back the result. The last trace
> messages of the crashed process are always the same:
> #### Communication failure. Connection closed.
> tcpSocketMT Worker thread: exits.
> tcpSocketStrand::~Strand() close socket no. 25
> I'm not sure, but it seems to me, that the crash occurs, when the
> client-thread, who has called the server's method, terminates. The clients
> are multi-threaded.
> What can I do wrong in my code, to produce such behaviour?
> I haven't tried egcs 1.1.2 yet.
--
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