Ah, I got around to looking at the disassembly as well.
The instruction that fails is
movdqa %xmm0,(%r9,%rdi,1)
The contents of the input CPU registers rdi and r9 are
r9 = 7026104
rdi = 0
Now, I'm not that good at reading x86 assembler, but I'm pretty good at
Googling. If I've understood this correctly, movdqa expects a 16-byte
aligned memory address as input, and will throw an exception otherwise.
The contents of r9 is the value of intPtr, which is not on a 16-byte
boundary (7026104 % 16 = 8)
I'm not too familiar with the inner workings of Valgrind either, but
from what I can see it seems like the movdqa instruction is not executed
correctly - it should throw an exception but does not. Here's a small
test application that shows the problem:
#include <stdlib.h>
int main(void)
{
int * buffer = calloc(1, 255);
asm ( "movdqa %%xmm0, (%0, %%rdi, 1)" : : "r"(buffer + 1) : "%
xmm0" );
free(buffer);
return EXIT_SUCCESS;
}
On my system, this will run without any reported errors in Valgrind but
segfault in normal console. I built it with a few version of GCC and
CLang for good measure, it's always reproducible. Can anyone else
confirm this before I file a bug report?
(Also, again, I'm not too familiar with x86 assembler, the instruction
might be valid under some constraint I'm not aware of. I'm happy to
learn though. :-)
// Christoffer
tis 2010-08-10 klockan 09:14 +0200 skrev Bart Van Assche:
> On Mon, Aug 9, 2010 at 4:01 PM, Christoffer Haglund
> <[email protected]> wrote:
>
> That's interesting. This what Memcheck tells me about the
> application that crashes:
>
> $ valgrind --leak-check=full --show-reachable=yes
> --track-origins=yes ./unittest_t9write -r api -o api.xml
> ==19513== Memcheck, a memory error detector
> ==19513== Copyright (C) 2002-2009, and GNU GPL'd, by Julian
> Seward et al.
> ==19513== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun
> with -h for copyright info
> ==19513== Command: ./unittest_t9write -r api -o api.xml
> ==19513==
>
> This is t9write unit test runner, compiled with: -Wall -Wextra
> -ansi -pedantic -O3
>
> No errors.
>
> ==19513==
> ==19513== HEAP SUMMARY:
> ==19513== in use at exit: 0 bytes in 0 blocks
> ==19513== total heap usage: 1,050,205 allocs, 1,050,205
> frees, 268,688,656 bytes allocated
> ==19513==
> ==19513== All heap blocks were freed -- no leaks are possible
> ==19513==
> ==19513== For counts of detected and suppressed errors, rerun
> with: -v
> ==19513== ERROR SUMMARY: 0 errors from 0 contexts (suppressed:
> 4 from 4)
>
>
> So Memcheck does not find any overwrites, but that's likely
> the problem anyway; using GDB I can see that the segfault
> occurs inside a loop that's basically a memset:
>
> for ( ; n > 0; n-- )
> *intPtr++ = value;
>
> Now, I haven't checked out exactly what instructions are
> generated, and I probably won't unless anyone finds this
> interesting or think it looks like a Memcheck bug :-)
>
>
>
> Does intPtr point to an array or to dynamically allocated memory ?
>
> Bart.
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
