On Mon, Aug 9, 2010 at 4:01 PM, Christoffer Haglund <Christoffer.Haglund@nuance.com> 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

This is t9write unit test runner, compiled with: -Wall -Wextra -ansi -pedantic -O3

No errors.

==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== All heap blocks were freed -- no leaks are possible
==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 ?