[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: alignement or compiler bug?
Emmanuel Dreyfus <manu%netbsd.org@localhost> wrote:
> This code wil rarely crash in memcpy(). gdb shows an unexpectely huge
> data_len, bigger than max_write. My explanation this that memcpy overwrite
> data_len becaue (fwi +1) did not hold the expected value.
data_len as reported by gdb in the caller's frame or as observed as
the argument to memcpy()? If the code was compiled with optimiztions
gdb may show garbage values.
> Here is the assembly leading to memcpy. The 0x28 is sizeof(*fwi), which
> suggests a correct (fwi + 1)
> 0xbbbe14dc <perfuse_node_write+460>: mov %eax,0x20(%esi)
> 0xbbbe14df <perfuse_node_write+463>: lea 0x28(%esi),%edx
> 0xbbbe14e2 <perfuse_node_write+466>: mov 0x10(%ebp),%eax
> 0xbbbe14e5 <perfuse_node_write+469>: add 0xffffffe8(%ebp),%eax
> 0xbbbe14e8 <perfuse_node_write+472>: push %edi
> 0xbbbe14e9 <perfuse_node_write+473>: push %eax
> 0xbbbe14ea <perfuse_node_write+474>: push %edx
> 0xbbbe14eb <perfuse_node_write+475>: call 0xbbbdfd90 <memcpy@plt>
data_len is in %edi and this snippet doesn't show how it's computed.
0xbbbe14dc <perfuse_node_write+460>: mov %eax,0x20(%esi)
looks like assignment to fwi->flags (just prior to memcpy) at offset
0x20 from %esi, that contains fwi - which is consistent with
0xbbbe14df <perfuse_node_write+463>: lea 0x28(%esi),%edx
for fwi+1, passed as the first argument to memcpy.
It's hard to tell anything else without seeing complete disassembly of
>> - Leave the "data" variable there, including the code you added to set
>> it, but still pass fwi+1 to the memcpy.
> I tried passing data, it still crashed. It seems to be the test that
> saves my day:
> if (data != ((char *)fwi) + sizeof(*fwi))
Since i386 is short on register, this check may strain register
allocator just enough to change the way code is generated.
Main Index |
Thread Index |