Re: alignement or compiler bug?

[uwe%stderr.spb.ru@localhost (Valeriy E. Ushakov)]

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
the function.


>> - 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.


-uwe