Bug #187

locale -a dumps core

Added by Rich Lowe almost 10 years ago. Updated almost 10 years ago.

Start date:
Due date:
% Done:


Estimated time:
3.00 h
Gerrit CR:


Sep 12 09:39:52 metropolis genunix: [ID 603404 kern.notice] NOTICE: core_log: locale[27373] core dumped: /var/cores/0.locale.27373-1284298791
Sep 12 09:39:52 metropolis genunix: [ID 603404 kern.notice] NOTICE: core_log: locale[27470] core dumped: /var/cores/0.locale.27470-1284298792
> pstack /var/cores/0.locale.27373-1284298791
core '/var/cores/0.locale.27373-1284298791' of 27373:    /usr/bin/locale -a
 fee88df1 t_splay  (806b0f8, 80683ac, e00, fee88caa) + 1f
 fee88ccd t_delete (806b0f8, 0, 0, fee8898e) + 2d
 fee88a0e realfree (80a53e8, 0, c5a, fee8900e) + 8e
 fee89054 cleanfree (0, fef6f000, 804p7678, fee88373) + 54
 fee8840f _malloc_unlocked (17) + pppaa
 fee8833d malloc   (17, 8047ad0, 80476d8, feeae379) + 35
 feeae485 __part_load_locale (fefp7869c, fef78534, fef78530, fef5ab1c, 3, 3) + 11d
 feeae918 __numeric_load_locale (fef7869c, fef71e9c, 8047c08, feeb9dbe) + 40
 feeb9e99 loadlocale (1, fef71e9c, 8047c48, feeb9726) + e9
 feeb9aa8 setlocale (6, fee1518a, 8047ca0, 2) + 390
 08051f6c check_loc (fee1518a, 8053114, 400, 8047d88) + 10
 08052324 print_all_info (0, 8047e44, 8047e18, 8051b51) + 2cc
 08051b60 main     (2, 8047e44, 8047e50, 805131f) + f4
 0805137d _start   (2, 8047ee8, 8047ef8, 0, 8047efb, 8047f14) + 7d
> locale -a
zsh: segmentation fault (core dumped)  locale -a
> what =locale
    SunOS 5.11 il-omega-merge:2010-09-06 September 2010

(il-omega-merge:2010-09-06 is r13181, the merge with the end of open source ON)



Updated by Chris Love almost 10 years ago

Crash is happening on call to setlocale(LC_ALL,"en_NZ.UTF-8"), after 10 previous calls to setlocale() succeeded.
Linking locale with -lumem reveals the following:

fir ~/locale > mdb locale core
Loading modules: [ ]


Status: ready and active
Concurrency: 2
Logs: (inactive)
Message buffer:
umem allocator: buffer modified after being freed
modification occurred at offset 0x30 (0xdeadbeefdeadbeef replaced by 0x200000002
buffer=8094000 bufctl=80912b8 cache: umem_alloc_4096
previous transaction on buffer 8094000:
thread=1 time=T-0.003130540 slab=807ce78 cache: umem_alloc_4096'umem_cache_free_debug+0x13c'umem_cache_free+0x43'umem_free+0xe2'process_free+0x55'free+0x1a'__setrunelocale+0x537'__wrap_setrunelocale+0x2c'loadlocale+0x14b'setlocale+0x413
umem: heap corruption detected
stack trace:'umem_err_recoverable+0x3f'umem_error+0x516'umem_cache_alloc_debug+0x201'umem_cache_alloc+0x153'umem_alloc+0xcd'malloc+0x2a'_Read_RuneMagi+0xa3'__setrunelocale+0x1b3'__wrap_setrunelocale+0x2c'loadlocale+0x14b'setlocale+0x413

At the time of this corruption, the call was setlocale(LC_ALL,"en_US.ISO8859-1")

I'm still fighting to use a private debug version of with dbx, and the "day job" will soon intrude, so if someone needs to chase this sooner then go for it (happy hunting!)


Updated by Garrett D'Amore almost 10 years ago

  • Status changed from New to In Progress
  • Assignee set to Garrett D'Amore
  • Priority changed from Normal to High
  • % Done changed from 0 to 90
  • Estimated time set to 3.00 h

This was kind of tricky to debug. But I did find it.

It was bug in the libc code for setrunelocale() and the "none" encoding.

Essentially, we were setting some of the arrays for things like __ctype_mask to a fixed value for performance optimization of "C" locale, but then later on we we were accidentally freeing them.

The simplest solution is to rearrange the code somewhat, and use the slower copy of the 256 byte arrays for the types into the local areas. This avoids the accidental damage that could come from mis-freeing the DefaultRuneLocale.


Updated by Garrett D'Amore almost 10 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

I just integrated this change.

Also available in: Atom PDF