wchar_t valgrind issue - Niepoprawny odczyt rozmiaru 8

Question

Nie jestem w stanie ustalić, dlaczego Valgrind drukuje Invalid read of size 8 podczas korzystania z wchar_t. Używam 64-bitowego systemu Ubuntu (3.5.0-25) z valgrind-3.7.0 i gcc 4.7.2.

#include <stdio.h> 
#include <wchar.h> 
#include <stdlib.h> 
#include <string.h> 

int main() 
{ 
    // const wchar_t *text = L"This is a t"; // no Valgrind error 
    // const wchar_t *text = L"This is a teeeeeeee"; // no Valgrind error 
    const wchar_t *text = L"This is a test"; // Valgrind ERRROR 

    wchar_t *new_text = NULL; 

    new_text = (wchar_t*) malloc((wcslen(text) + 1) * sizeof(wchar_t)); 
    wcsncpy(new_text, text, wcslen(text)); 
    new_text[wcslen(text)] = L'\0'; 

    printf("new_text: %ls\n", new_text); 

    free(new_text); 

    return 0; 
} 

opracowują:

$ gcc -g -std=c99 test.c -o test 
$ valgrind --tool=memcheck --leak-check=full --track-origins=yes --show-reachable=yes ./test 

Valgrind Wyniki:

==19495== Memcheck, a memory error detector 
==19495== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. 
==19495== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info 
==19495== Command: ./test 
==19495== 
==19495== Invalid read of size 8 
==19495== at 0x4ED45A7: wcslen (wcslen.S:55) 
==19495== by 0x4ED5C0E: wcsrtombs (wcsrtombs.c:74) 
==19495== by 0x4E7D160: vfprintf (vfprintf.c:1630) 
==19495== by 0x4E858D8: printf (printf.c:35) 
==19495== by 0x4006CC: main (test.c:16) 
==19495== Address 0x51f1078 is 56 bytes inside a block of size 60 alloc'd 
==19495== at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==19495== by 0x40066F: main (test.c:12) 
==19495== 
new_text: This is a test 
==19495== 
==19495== HEAP SUMMARY: 
==19495==  in use at exit: 0 bytes in 0 blocks 
==19495== total heap usage: 1 allocs, 1 frees, 60 bytes allocated 
==19495== 
==19495== All heap blocks were freed -- no leaks are possible 
==19495== 
==19495== For counts of detected and suppressed errors, rerun with: -v 
==19495== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) 

Teraz jeśli uruchomię to samo, ale z 'ciągiem roboczym', powiedzmy

const wchar_t *text = L"This is a t"; // no Valgrind error 
// const wchar_t *text = L"This is a teeeeeeee"; // no Valgrind error 
// const wchar_t *text = L"This is a test"; // Valgrind ERRROR 

I nie ma problemu:

==19571== Memcheck, a memory error detector 
==19571== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. 
==19571== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info 
==19571== Command: ./test 
==19571== 
new_text: This is a t 
==19571== 
==19571== HEAP SUMMARY: 
==19571==  in use at exit: 0 bytes in 0 blocks 
==19571== total heap usage: 1 allocs, 1 frees, 48 bytes allocated 
==19571== 
==19571== All heap blocks were freed -- no leaks are possible 
==19571== 
==19571== For counts of detected and suppressed errors, rerun with: -v 
==19571== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) 

Na początku myślałem, że rozmiar ciąg powinien być zawsze być wielokrotnością 8 (być może niektóre toalety czytać fragmenty 8), ale w niektórych przypadkach nie udało, potem pomyślałem, że trzeba dołączyć zawsze 8 bajtów na terminator NULL ((wcslen(item) + 2) * sizeof(wchar_t)), zadziałało, ale to nie ma sensu, ponieważ sizeof(wchar_t) - w moim systemie - ma 4 bajty i powinno wystarczyć do obsługi terminatora L'\0'.

Przeczytałem również kod źródłowy glibc wcslen, ale nic nowego. Teraz myślę o kwestii Valgrinda. Czy możecie tu rzucić trochę światła? Czy warto zgłosić błąd przeciwko Valgrind?

Dziękuję

Answer 1

Jest to prawdopodobnie spowodowane przez optymalizację SSE funkcji wcslen; patrz np. https://bugzilla.redhat.com/show_bug.cgi?id=798968 lub https://bugs.archlinux.org/task/30643.

Podczas optymalizacji wcslen szybciej jest czytać wiele szerokich znaków naraz i używać wektorowych instrukcji (SSE) w celu ich porównania z L'\0'. Niestety valgrind widzi to jako niezainicjowany odczyt - który jest, ale jest nieszkodliwy, ponieważ wynik wcslen nie zależy od niezainicjowanej wartości.

Poprawka polega na aktualizacji valgrindu w nadziei, że nowsza wersja pominie fałszywy alarm.