Oh, sorry, that last reply wasn't very clear, let my try again. The
problem occurs inside some proprietary code, so unfortunately I can't
just copy the exact code that fails, but I'll try to describe it.
There's a struct with the following definition
typedef struct _session {
...
char generic_buffer[255];
} session_t;
Before triggering the segfault, the session is allocated with
session_t * pSession = calloc(get_session_size());
The function that segfaults (that contains the loop I was referring to
earlier) is called with
status = do_stuff(input, &pSession->generic_buffer[0]);
The function has the following definition:
status_t do_stuff(input_t * input, char * charPtr)
{
int n = calculate_n(input);
int value = calculate_value(input);
int * intPrt = (int *) charPtr;
for ( ; n < 0; n-- )
*intPtr++ = value;
}
...and when debugging I can see that calculate_n() returns 27 and
calculate_value() returns 0x000000 for the test case when the
application fails (which are correct values, compared to when the
application is built with another compiler or with
"-fno-tree-vectorize").
// 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.
// 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
