Bug 298281 - wcslen causes false(?) uninitialised value warnings
Summary: wcslen causes false(?) uninitialised value warnings
Status: REPORTED
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (show other bugs)
Version: 3.7.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-17 08:05 UTC by Anders Kaseorg
Modified: 2012-04-17 08:55 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anders Kaseorg 2012-04-17 08:05:00 UTC
On Ubuntu precise (libc6 2.15-0ubuntu9, valgrind 3.7.0-0ubuntu3), wcslen() sometimes causes uninitialised value warnings in what seems to be correct code.  I think valgrind is getting confused by the optimized assembly implementations of wcslen that read the string in large blocks.

$ cat test.c
#include <stdio.h>
#include <wchar.h>
int main()
{
    wchar_t tmp[10];
    swprintf(tmp, 10, L"aaaaaaaa");
    return wcslen(tmp);
}
$ gcc -m32 -g -Wall test.c -o test && valgrind --track-origins=yes ./test
==4735== Memcheck, a memory error detector
==4735== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==4735== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==4735== Command: ./test
==4735== 
==4735== Conditional jump or move depends on uninitialised value(s)
==4735==    at 0x49B0461: __wcslen_sse2 (wcslen-sse2.S:57)
==4735==    by 0x49264D2: (below main) (libc-start.c:226)
==4735==  Uninitialised value was created by a stack allocation
==4735==    at 0x804842A: main (test.c:4)
==4735== 
==4735== Conditional jump or move depends on uninitialised value(s)
==4735==    at 0x49B0527: __wcslen_sse2 (wcslen-sse2.S:128)
==4735==    by 0x49264D2: (below main) (libc-start.c:226)
==4735==  Uninitialised value was created by a stack allocation
==4735==    at 0x804842A: main (test.c:4)
==4735== 
==4735== Conditional jump or move depends on uninitialised value(s)
==4735==    at 0x49B0545: __wcslen_sse2 (wcslen-sse2.S:139)
==4735==    by 0x49264D2: (below main) (libc-start.c:226)
==4735== 
==4735== 
==4735== HEAP SUMMARY:
==4735==     in use at exit: 0 bytes in 0 blocks
==4735==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==4735== 
==4735== All heap blocks were freed -- no leaks are possible
==4735== 
==4735== For counts of detected and suppressed errors, rerun with: -v
==4735== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
$ gcc -m64 -g -Wall test.c -o test && valgrind --track-origins=yes ./test
==4746== Memcheck, a memory error detector
==4746== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==4746== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==4746== Command: ./test
==4746== 
==4746== Conditional jump or move depends on uninitialised value(s)
==4746==    at 0x4ED4031: wcslen (wcslen.S:53)
==4746==    by 0x400572: main (test.c:7)
==4746==  Uninitialised value was created by a stack allocation
==4746==    at 0x400544: main (test.c:4)
==4746== 
==4746== Conditional jump or move depends on uninitialised value(s)
==4746==    at 0x4ED4199: wcslen (wcslen.S:172)
==4746==    by 0x400572: main (test.c:7)
==4746==  Uninitialised value was created by a stack allocation
==4746==    at 0x400544: main (test.c:4)
==4746== 
==4746== Conditional jump or move depends on uninitialised value(s)
==4746==    at 0x4ED41A0: wcslen (wcslen.S:176)
==4746==    by 0x400572: main (test.c:7)
==4746==  Uninitialised value was created by a stack allocation
==4746==    at 0x400544: main (test.c:4)
==4746== 
==4746== 
==4746== HEAP SUMMARY:
==4746==     in use at exit: 0 bytes in 0 blocks
==4746==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==4746== 
==4746== All heap blocks were freed -- no leaks are possible
==4746== 
==4746== For counts of detected and suppressed errors, rerun with: -v
==4746== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 2 from 2)
Comment 1 Julian Seward 2012-04-17 08:55:13 UTC
Hmm, there was a patch drifting around, that fixed this.  Not sure
where it got to -- it either got filed as a bug, or is on the dev- or users-
lists.  Within the last month IIRC.  I can't find from a quick look around
those, though.