in debian bug http://bugs.debian.org/443660 was reported a crash due to 
dgettext in a multi-threaded context.

It was reported that when it crashes (as it seems to be a race, it's hard to) 
a valgrind trace looks like that:

==3535== Thread 3:
==3535== Invalid read of size 4
==3535==    at 0x4063F0B: _nl_find_msg (dcigettext.c:862)
==3535==    by 0x4064A41: __dcigettext (dcigettext.c:639)
==3535==    by 0x4063972: dcgettext (dcgettext.c:53)
==3535==    by 0x406399F: dgettext (dgettext.c:54)
==3535==    by 0x80484DD: run (in /home/remi/a.out)
==3535==    by 0x402D2D2: start_thread (pthread_create.c:296)
==3535==    by 0x41124ED: clone (in /usr/lib/debug/libc-2.6.1.so)
==3535==  Address 0x418C91C is 0 bytes after a block of size 12 alloc'd
==3535==    at 0x4024862: realloc (vg_replace_malloc.c:306)
==3535==    by 0x4063FF1: _nl_find_msg (dcigettext.c:876)
==3535==    by 0x4064A41: __dcigettext (dcigettext.c:639)
==3535==    by 0x4063972: dcgettext (dcgettext.c:53)
==3535==    by 0x406399F: dgettext (dgettext.c:54)
==3535==    by 0x80484DD: run (in /home/remi/a.out)
==3535==    by 0x402D2D2: start_thread (pthread_create.c:296)
==3535==    by 0x41124ED: clone (in /usr/lib/debug/libc-2.6.1.so)


THe second block looks indeed fishy, as I seem to understand that the realloc 
is perfomed on a shared data, without locking.