Project Home
Project Home
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - Is it possible for a byte to be corrupted on reading from memory?: (1 Item)
   
Is it possible for a byte to be corrupted on reading from memory?  
Hi All,

I have a very strange crash in my program (QNX 6.3.0 SP3 on V611 board). The process has been terminated by signal 11.

> Program terminated with signal 11, Segmentation fault.
> #0  0x0810c916 in CAxisSerialDeviceMIB::ProcessMIBRcvPortDataSence (this=0x82a2e70, sdata=8255)

The execution point at the moment of crash was 0x810c916.
 
(gdb) i fr
Stack level 0, frame at 0x7d578a4:
 eip = 0x810c916 in CAxisSerialDeviceMIB::ProcessMIBRcvPortDataSence(int) (/home/oder/backend-src/Src/Nav/Axis/Server/
AxisSerialDevice.h:42); saved eip 0x810c4ba
 called by frame at 0x7d58414
 source language c++.
 Arglist at 0x7d5789c, args: this=0x82a2e70, sdata=8255
 Locals at 0x7d5789c, Previous frame's sp is 0x7d578a4
 Saved registers:
  ebx at 0x7d57890, ebp at 0x7d5789c, esi at 0x7d57894, edi at 0x7d57898, eip at 0x7d578a0

At that address there is an invocation of CAxisWrapper::HandleHLimit() virtual method.
 
	Axis()->HandleHLimit(false, false, hw_hlim_minus);

0x0810c903 <_ZN20CAxisSerialDeviceMIB26ProcessMIBRcvPortDataSenceEi+131>:       mov    0x4(%esi),%ecx // A inlined call 
to Axis() with "this" in %esi
0x0810c906 <_ZN20CAxisSerialDeviceMIB26ProcessMIBRcvPortDataSenceEi+134>:       add    $0x10,%esp // This is a stack 
correction after previous call
0x0810c909 <_ZN20CAxisSerialDeviceMIB26ProcessMIBRcvPortDataSenceEi+137>:       xor    %edx,%edx // Zero register for 
the third parameter
0x0810c90b <_ZN20CAxisSerialDeviceMIB26ProcessMIBRcvPortDataSenceEi+139>:       mov    -0xe(%ebp),%dl // Load third 
parameter (actual value is 0 -- can be determined from function parameters)
0x0810c90e <_ZN20CAxisSerialDeviceMIB26ProcessMIBRcvPortDataSenceEi+142>:       mov    (%ecx),%ebx // VMT of the object
0x0810c910 <_ZN20CAxisSerialDeviceMIB26ProcessMIBRcvPortDataSenceEi+144>:       push   %edx // Push third parameter
0x0810c911 <_ZN20CAxisSerialDeviceMIB26ProcessMIBRcvPortDataSenceEi+145>:       push   $0x0 // Push second parameter 
(false)
0x0810c913 <_ZN20CAxisSerialDeviceMIB26ProcessMIBRcvPortDataSenceEi+147>:       push   $0x0 // Push first parameter 
(false)
0x0810c915 <_ZN20CAxisSerialDeviceMIB26ProcessMIBRcvPortDataSenceEi+149>:       push   %ecx // Push "this" pointer
0x0810c916 <_ZN20CAxisSerialDeviceMIB26ProcessMIBRcvPortDataSenceEi+150>:       call   *0x178(%ebx) // Call the virtual 
method

From code fragment above, %esi should contain "this" pointer of CAxisSerialDeviceMIB instance, %ecx should be loaded 
with the pointer to CDacAxis instance (a descendant of CAxisWrapper) and %ebx should contain its VMT pointer.
 
The register examination shows the followin values for these registers:
 
(gdb) i reg
eax            0x0      0
ecx            0x82e6dd2        137260498
edx            0x0      0
ebx            0x6b     107
esp            0x7d57874        0x7d57874
ebp            0x7d5789c        0x7d5789c
esi            0x82a2e70        136982128
edi            0x203f   8255
eip            0x810c916        0x810c916 <CAxisSerialDeviceMIB::ProcessMIBRcvPortDataSence(int)+150>
eflags         0x13206  [ PF IF #12 #13 RF ]
cs             0xf3     243
ss             0xfb     251
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0

Here, %esi looks like a normal pointer, %ecx is misaligned (not divisible by 4), which is wrong, and %ebx contains 
obvious junk.
 
If to check the values in memory
 
(gdb) p {struct CAxisSerialDeviceMIB}0x82a2e70
$2 = {<CAxisSerialDevice> = {_vptr.CAxisSerialDevice = 0x8253868, m_axis = 0x82e6d68, m_portreg = 34, m_portmsk = 2, 
m_bypassed = false, m_inES = false,
    m_DevIDreq_send_timeout_time = 267375169585, m_DevIDreq_recv_timeout_time = 0, m_DevIDreq_replied = true, 
m_reconnect_confirmation_mode = false,
    m_reconnect_confirmation_sent = false, m_disconnect_bypass = false, m_board_id = 55,
    m_btn_mf_info =...
View Full Message