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 :-)
// Christoffer
mån 2010-08-09 klockan 14:43 +0200 skrev Julian Seward:
> This is a known phenomenon. Valgrind (well, Memcheck, really) is more
> robust against applications that overwrite the ends/beginnings of heap blocks
> than the normal C malloc/free routines are. So if your application
> is doing such overwrites, that could explain the difference. What
> really would be a bug in Memcheck though is if it doesn't tell you
> about such overruns.
>
> J
>
> On Monday, August 09, 2010, Christoffer Haglund wrote:
> > Hi,
> >
> > here's a little problem that has bothered me for a few days. I'm working
> > on isolating it further but thought there might be someone here who
> > might just know if this is expected behaviour of Valgrind, or if this is
> > something that should be reported as a bug.
> >
> > As the title says, I've managed to build an application that runs
> > correctly in Valgrind, but crashes with a segmentation fault when run
> > normally in a console. It's a normal C89 application, built with GCC on
> > a x86_64 machine. The culprit seems to be the auto-vectorization module
> > (which vectorizes some loops using SSE instructions). The segfault
> > occurs inside a loop that is reported as vectorized (with
> > -ftree-vectorizer-verbose=2), and the application runs as expected both
> > in Valgrind an in console when built with -fno-tree-vectorize.
> >
> > Now, I'm not saying that the compiler or code is flawless, but I had
> > expected the application to crash in Valgrind as well :-)
> >
> > The Valgrind version is reported as 3.6.0.SVN-Debian
> > GCC version 4.4.3 and 4.3.4 displays the mentioned behaviour, when
> > building with 4.1.3 the application works both in Valgrind and in the
> > console when vectorization is enabled.
> >
> > // Christoffer
> > _____________________________________________
> >
> > CHRISTOFFER HAGLUND
> > Software Developer, Decuma
> >
> > Nuance Communications Sweden
> > Ole Römers väg 16
> > SE-223 70 Lund
> > +46 (0) 46 286 53 43 Office
> > +46 (0) 709 59 63 06 Mobile
> > NUANCE.COM
> > The experience speaks for itself ™
>
------------------------------------------------------------------------------
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
