Oleh Derevenko(deleted)
|
Is it possible for a byte to be corrupted on reading from memory?
|
Oleh Derevenko(deleted)
01/20/2009 6:49 AM
post20365
|
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
|
|
|