[omniORB] Memory corruption when using omniORB 4.1.4 with SLES 11 64-bit

[Jingdong Sun]

All trace points are from omniORB, how do you think it is a bug in my 
code? 
Can you point to me some examples of what possible bug in my code that can 
make this kind memory corruption happen from omniORB?

Thanks.
Jingdong Sun
InfoSphere Streams Development
Phone  507 253-5958  (T/L 553-5958) 
jindong at us.ibm.com



From:   姜维 <sdjiangwei at gmail.com>
To:     Jingdong Sun/Rochester/IBM at IBMUS, 
Cc:     omniorb-list at omniorb-support.com
Date:   03/27/2013 08:22 PM
Subject:        Re: [omniORB] Memory corruption when using omniORB 4.1.4 
with SLES 11 64-bit



It's very likely to be a bug in your code.




2013/3/28 Jingdong Sun <jindong at us.ibm.com>
Hi, There, 

I am using omniORB 4.1.4 with my project. 
Recently, when I testing with SLES, I noticed that, the server side hit 
memory corruption some time (not always). 

With ORBtraceLevel set to 45, I got following trace information: 
omniORB: (7) inputMessage: from giop:tcp:[::ffff:10.6.25.60]:56354 2048 
bytes 
omniORB: (7) 
4749 4f50 0102 0300 6467 0000 0a00 0000 GIOP....dg...... 
0300 0000 0000 0000 0e00 0000 fed6 ef51 ...............Q 
5100 0034 2e00 0000 0000 6f72 0800 0000 Q..4......or.... 
7374 6172 7450 4500 0000 0000 2234 3522 startPE....."45" 
2e67 0000 3c3f 786d 6c20 7665 7273 696f .g..<?xml versio 
6e3d 2231 2e30 2220 656e 636f 6469 6e67 n="1.0" encoding 
3d22 5554 462d 3822 2073 7461 6e64 616c ="UTF-8" standal 
6f6e 653d 226e 6f22 203f 3e0a 3c61 7567 one="no" ?>.<aug 
(Jingdong: I skipped some lines here......) 
2020 3c74 743a 6174 7472 206e 616d 653d   <tt:attr name= 
omniORB: (7) inputCopyChunk: from giop:tcp:[::ffff:10.6.25.60]:56354 24432 
bytes 
omniORB: (7) 
2263 6861 696e 4964 2220 7479 7065 3d22 "chainId" type=" 
696e 7433 3222 2f3e 0a20 2020 2020 203c int32"/>.      < 
(Jingdong: I skipped some lines here too.....) 
(Jingdong: following part is corrupted, not the contents as I expected). 
3020 3820 3020 3020 3020 3020 3120 3120 0 8 0 0 0 0 1 1 
3020 3020 3020 3120 3120 340a 3120 3435 0 0 0 1 1 4.1 45 
omniORB: (7) inputMessage: from giop:tcp:[::ffff:10.6.25.60]:56354 18 
bytes 
omniORB: (7) 
4749 4f50 0102 0107 0600 0000 0a00 0000 GIOP............ 
0a00     

What I noticed are: 
1. The memory corruption problem not happened all the time, and when 
problem happened, generally the 2nd try will pass. 
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. 
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) 
omniORB: (7) inputCopyChunk: from giop:tcp:[::ffff:10.6.25.60]:56354 24432 
bytes 
4. When corruption happened, sometimes the content just got truncated, 
sometimes the contents just replaced by some meaningless  contents at the 
end. 

Please help me. 
Thanks. 
Jingdong Sun
InfoSphere Streams Development
Phone  507 253-5958  (T/L 553-5958)  
jindong at us.ibm.com
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20130327/6291bb27/attachment-0001.html>