mbsrtowcs + uselocale == leaks

[Benjamin Kosnik]

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;
}

-------------- next part --------------
A non-text attachment was scrubbed...
Name: valgrind.out
Type: application/octet-stream
Size: 10069 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20021105/b995c631/attachment.obj>