<html><body>
<p><tt><font size="2">Hi, </font></tt><br>
<br>
<tt><font size="2">> Somehow, when omniORB tries to receive a message, it gets the correct<br>
> length for the message, but has the old data. Now, omniORB gets the data<br>
> by calling recv() on the socket, giving it a buffer. The buffer is<br>
> reused between messages, so it contains the old data at the time recv()<br>
> is called. recv() returns the correct message length, but either it<br>
> fills the buffer with the old data, or it doesn't fill the buffer at<br>
> all, leaving the old data. Either way, it looks to me like an OS /<br>
> platform bug rather than an omniORB bug.<br>
<br>
> It might be illuminating to edit src/lib/omniORB/orbcore/giopStream.cc<br>
> in inputMessage so it uses memset to clear the data just before calling<br>
> Recv. That will show if recv is returning old data or not returning data<br>
> at all.</font></tt><br>
<br>
<tt><font size="2">inserted a memset of 0x right before tcp::recv call. for the bad call, the buffer remains</font></tt><br>
<tt><font size="2">all zero's. so, it looks like no data is being transferred.</font></tt><br>
<br>
<tt><font size="2">yes, it does look like a OS/platform bug in most ways. currently pursuing the tcp recv</font></tt><br>
<tt><font size="2">code to understand what conditions would cause it to return 0 bytes, but profess something different.</font></tt><br>
<tt><font size="2">also, the IOATDMA (dma transfer support for TCP) seems to be involved in this picture. when it is </font></tt><br>
<tt><font size="2">disabled, the data is transferred correctly. when it is enabled, the data is not transferred.</font></tt><br>
<br>
<tt><font size="2">but the curious thing is that it is so darn consistent with relationship to the CORBA calls. </font></tt><br>
<tt><font size="2">It is always on the 23rd corba call of this testcase. & is not dependent upon timing between </font></tt><br>
<tt><font size="2">CORBA requests. & if is a pure tcp/OS bug, then wouldn't it be appearing more often in other cases?</font></tt><br>
<br>
<tt><font size="2">current theory is that there is something special in the way CORBA manages the TCP connections such that it</font></tt><br>
<tt><font size="2">exposes a bug in the tcp::recv code with ioatdma driver installed.</font></tt><br>
<br>
<tt><font size="2">can u think of anything from the corba side of things that would happen that might interrupt a tcp::recv before it completes successfully? does it do many peeks? or selects? or something like that? are the any trace points you would suggest inserting to see what is happening during this time?</font></tt><br>
<tt><font size="2"><br>
Thanks,</font></tt><br>
<br>
<tt><font size="2">Brad.</font></tt></body></html>