Comment 6 for bug 442272

While searching for coreutils bugs I found a series of 'SIGSEGV in setlocale". I am still investigating this, but I am going to set this bug as the master bug to track.

In pretty much all stacktraces I have looked at, the failure signature is the same. Also, in pretty much all of them the frame for __GI_setlocale has entries similar to this:

#3 0x00e58aa9 in *__GI_setlocale (category=0, locale=0x804dc36 "")
    at setlocale.c:303
 newnames = {0xbffe5ea0 "en_US.UTF8", 0x8a61818 "en_US.UTF8",
  0x8a611d0 "en_US.UTF8", 0x8a60990 "en_US.UTF8", 0x8a602b0 "en_US.UTF8",
  0x8a5fb20 "en_US.UTF8", 0x8050068 "@\210å", 0x8a5f498 "en_US.UTF8",
  0x8a5ee60 "en_US.UTF8", 0x8a5e808 "en_US.UTF8", 0x8a5e100 "en_US.UTF8",
  0x8a5da40 "en_US.UTF8", 0x8a5c170 "en_US.UTF8"}
 newdata = {0x0, 0x8a617d8, 0x8a60fe8, 0x8a60918, 0x8a601d0,
  0x8a5fae0, 0xffffffff, 0x8a5f460, 0x8a5d2c8, 0x8a5e7a8, 0x8a5e0c0,
  0x8a5d8c8, 0x8a5d310}
 locale_path = 0x0
 locale_path_len = 0
 locpath_var = <value optimized out>
 composite = <value optimized out>

Now, if we look at 'newnames' array, we will see that the seventh entry is weird: 0x8050068 "@\210å".

This sounds very much like a memory issue (overrun?).

I will start dupping the other similar bugs here.

Meanwhile, I am confirming this.