This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
This is representative of the last memory-type issue for the C++ libraries. It has to do with using mbsrtowcs and named locales. In the code below, if the mbsrtowcs block is active without the uselocale/freelocale blocks below, no leaks. If just the uselocale/free locale blocks are active without the mbsrtowcs block, no leaks. If both are active, then ==25125== LEAK SUMMARY: ==25125== definitely lost: 16 bytes in 1 blocks. ==25125== possibly lost: 0 bytes in 0 blocks. ==25125== still reachable: 936 bytes in 7 blocks. I'm running valgrind like so: #!/bin/bash FILE=$1 FLAGS="-v --num-callers=20 --leak-check=yes --leak-resolution=high --show-reachable=yes" valgrind $FLAGS $FILE This is on RH 8.0, with gcc-3_2-branch compilers and Jakub's glibc-2.3.1-2 rpms. Attached is the full valgrind output. #include <malloc.h> #include <locale.h> int main() { #if 1 const char* __s = "fr_FR"; __locale_t __cloc = newlocale(1 << LC_ALL, __s, NULL); __locale_t __old = uselocale(__cloc); #endif #if 1 wchar_t* _M_negative_sign; const char* __cnegsign = "-"; size_t __len = strlen(__cnegsign); if (__len) { ++__len; mbstate_t __state; memset(&__state, 0, sizeof(mbstate_t)); wchar_t* __wcs = malloc(sizeof(wchar_t[__len])); mbsrtowcs(__wcs, &__cnegsign, __len, &__state); _M_negative_sign = __wcs; } free(_M_negative_sign); #endif #if 1 uselocale(__old); freelocale(__cloc); #endif return 0; }
Attachment:
valgrind.out
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |