<font size=2 face="sans-serif">Hi, There,</font>
<br>
<br><font size=2 face="sans-serif">I am using omniORB 4.1.4 with my project.</font>
<br><font size=2 face="sans-serif">Recently, when I testing with SLES,
I noticed that, the server side hit memory corruption some time (not always).</font>
<br>
<br><font size=2 face="sans-serif">With ORBtraceLevel set to 45, I got
following trace information:</font>
<br><font size=2 face="Courier New">omniORB: (7) inputMessage: from giop:tcp:[::ffff:10.6.25.60]:56354
2048 bytes</font>
<br><font size=2 face="Courier New">omniORB: (7) </font>
<br><font size=2 face="Courier New">4749 4f50 0102 0300 6467 0000 0a00
0000 GIOP....dg......</font>
<br><font size=2 face="Courier New">0300 0000 0000 0000 0e00 0000 fed6
ef51 ...............Q</font>
<br><font size=2 face="Courier New">5100 0034 2e00 0000 0000 6f72 0800
0000 Q..4......or....</font>
<br><font size=2 face="Courier New">7374 6172 7450 4500 0000 0000 2234
3522 startPE....."45"</font>
<br><font size=2 face="Courier New">2e67 0000 3c3f 786d 6c20 7665 7273
696f .g..<?xml versio</font>
<br><font size=2 face="Courier New">6e3d 2231 2e30 2220 656e 636f 6469
6e67 n="1.0" encoding</font>
<br><font size=2 face="Courier New">3d22 5554 462d 3822 2073 7461 6e64
616c ="UTF-8" standal</font>
<br><font size=2 face="Courier New">6f6e 653d 226e 6f22 203f 3e0a 3c61
7567 one="no" ?>.<aug</font>
<br><font size=2 face="Default Sans
Serif">(Jingdong: I skipped some lines
here......)</font>
<br><font size=2 face="Courier New">2020 3c74 743a 6174 7472 206e 616d
653d <tt:attr name=</font>
<br><font size=2 face="Courier New">omniORB: (7) inputCopyChunk: from giop:tcp:[::ffff:10.6.25.60]:56354
24432 bytes</font>
<br><font size=2 face="Courier New">omniORB: (7) </font>
<br><font size=2 face="Courier New">2263 6861 696e 4964 2220 7479 7065
3d22 "chainId" type="</font>
<br><font size=2 face="Courier New">696e 7433 3222 2f3e 0a20 2020 2020
203c int32"/>. <</font>
<br><font size=2 face="Default Sans
Serif">(Jingdong: I skipped some lines
here too.....)</font>
<br><font size=2 face="Default Sans
Serif">(Jingdong: following part is
corrupted, not the contents as I expected).</font>
<br><font size=2 face="Courier New">3020 3820 3020 3020 3020 3020 3120
3120 0 8 0 0 0 0 1 1 </font>
<br><font size=2 face="Courier New">3020 3020 3020 3120 3120 340a 3120
3435 0 0 0 1 1 4.1 45</font>
<br><font size=2 face="Courier New">omniORB: (7) inputMessage: from giop:tcp:[::ffff:10.6.25.60]:56354
18 bytes</font>
<br><font size=2 face="Courier New">omniORB: (7) </font>
<br><font size=2 face="Courier New">4749 4f50 0102 0107 0600 0000 0a00
0000 GIOP............</font>
<br><font size=2 face="Courier New">0a00 </font>
<br>
<br><font size=2 face="sans-serif">What I noticed are:</font>
<br><font size=2 face="sans-serif">1. The memory corruption problem not
happened all the time, and when problem happened, generally the 2nd try
will pass.</font>
<br><font size=2 face="sans-serif">2. All corruptions happened to me so
far were related to relative big data (about 24K), and it happened related
to "inputCopyChunk" as trace shown above.</font>
<br><font size=2 face="sans-serif">3. The size server side got is correct,
even the content got corrupted. (The size 24432 bytes is correct in the
example I copied here)</font>
<br><font size=2 face="Courier New">omniORB: (7) inputCopyChunk: from giop:tcp:[::ffff:10.6.25.60]:56354
24432 bytes</font>
<br><font size=2 face="sans-serif">4. When corruption happened, sometimes
the content just got truncated, sometimes the contents just replaced by
some meaningless contents at the end.</font>
<br>
<br><font size=2 face="sans-serif">Please help me.</font>
<br><font size=2 face="sans-serif">Thanks.</font>
<br><font size=2 face="sans-serif">Jingdong Sun<br>
InfoSphere Streams Development<br>
Phone 507 253-5958 (T/L 553-5958) <br>
jindong@us.ibm.com</font>