Project

General

Profile

Bug #187

locale -a dumps core

Added by Rich Lowe over 9 years ago. Updated over 9 years ago.

Status:
Resolved
Priority:
High
Category:
-
Start date:
2010-09-12
Due date:
% Done:

100%

Estimated time:
3.00 h
Difficulty:
Tags:

Description

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
/usr/bin/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)

History

#1

Updated by Chris Love over 9 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: [ libumem.so.1 libc.so.1 ld.so.1 ]

::umem_status

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
0)
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
libumem.so.1'umem_cache_free_debug+0x13c
libumem.so.1'umem_cache_free+0x43
libumem.so.1'umem_free+0xe2
libumem.so.1'process_free+0x55
libumem.so.1'free+0x1a
libc.so.1'__setrunelocale+0x537
libc.so.1'__wrap_setrunelocale+0x2c
libc.so.1'loadlocale+0x14b
libc.so.1'setlocale+0x413
locale'check_loc+0x11
locale'print_all_info+0x1c9
locale'main+0x130
locale'_start+0x7d
umem: heap corruption detected
stack trace:
libumem.so.1'umem_err_recoverable+0x3f
libumem.so.1'umem_error+0x516
libumem.so.1'umem_cache_alloc_debug+0x201
libumem.so.1'umem_cache_alloc+0x153
libumem.so.1'umem_alloc+0xcd
libumem.so.1'malloc+0x2a
libc.so.1'_Read_RuneMagi+0xa3
libc.so.1'__setrunelocale+0x1b3
libc.so.1'__wrap_setrunelocale+0x2c
libc.so.1'loadlocale+0x14b
libc.so.1'setlocale+0x413
locale'check_loc+0x11
locale'print_all_info+0x1c9
locale'main+0x130
locale'_start+0x7d

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 libc.so.1 with dbx, and the "day job" will soon intrude, so if someone needs to chase this sooner then go for it (happy hunting!)

#2

Updated by Garrett D'Amore over 9 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.

#3

Updated by Garrett D'Amore over 9 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