This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug locale/22390] New: Rare memory corruption in localedef related to malloc
- From: "fweimer at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 03 Nov 2017 06:31:37 +0000
- Subject: [Bug locale/22390] New: Rare memory corruption in localedef related to malloc
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=22390
Bug ID: 22390
Summary: Rare memory corruption in localedef related to malloc
Product: glibc
Version: 2.26
Status: NEW
Severity: normal
Priority: P2
Component: locale
Assignee: unassigned at sourceware dot org
Reporter: fweimer at redhat dot com
Target Milestone: ---
We occasionally see a crash in localedef during “make install”. I was able to
capture a backtrace from a core file:
#0 sysmalloc (nb=nb@entry=1361968, av=av@entry=0x7fffbe400ed8 <main_arena>)
at malloc.c:2768
#1 0x00007fffbe2b0f64 in _int_malloc (av=0x7fffbe400ed8 <main_arena>,
bytes=1361953) at malloc.c:4134
#2 0x00007fffbe2b6c4c in _int_realloc (nb=1361968, oldsize=680992,
oldp=0x7fffffb52690, av=0x7fffbe400ed8 <main_arena>) at malloc.c:4626
#3 __GI___libc_realloc (oldmem=0x7fffffb526a0, bytes=1361952) at malloc.c:3245
#4 0x0000000010049684 in xrealloc (p=<optimized out>, n=<optimized out>)
at programs/xmalloc.c:102
#5 0x0000000010006938 in idx_table_add (value=105661, wc=<optimized out>,
t=0x7fffffb36438) at programs/3level.h:127
#6 find_idx (ctype=ctype@entry=0x7fffffb36420, table=0x7fffffb369a8,
table@entry=0xfbf, max=max@entry=0x7fffffb369b0,
act=act@entry=0x7fffffb369b8, idx=idx@entry=170244)
at programs/ld-ctype.c:1234
#7 0x000000001000fe78 in find_idx (idx=170244, act=<optimized out>,
max=<optimized out>, table=<optimized out>, ctype=<optimized out>)
at programs/ld-ctype.c:1526
#8 charclass_ucs4_ellipsis (ldfile=<optimized out>, ldfile=<optimized out>,
now=0x7fffffb362a0, step=1, handle_digits=<optimized out>,
ignore_content=<optimized out>, class_bit=<optimized out>,
class256_bit=<optimized out>, last_wch=170244, repertoire=<optimized out>,
charmap=<optimized out>, ctype=<optimized out>) at programs/ld-ctype.c:1542
#9 ctype_read (ldfile=<optimized out>, result=<optimized out>,
charmap=0x7ffffe0d0640, repertoire_name=<optimized out>,
ignore_content=<optimized out>) at programs/ld-ctype.c:2401
#10 0x000000001003c3ec in locfile_read (result=0x7fffffb35ed0,
charmap=0x7ffffe0d0640) at programs/locfile.c:173
#11 0x000000001000490c in load_locale (category=<optimized out>,
name=0x7fffffb35e90 "i18n", repertoire_name=0x0, charmap=0x7ffffe0d0640,
copy_locale=0x0) at programs/localedef.c:621
#12 0x0000000010010c9c in ctype_read (ldfile=0x7fffffb35d10,
result=0x7fffffb35980, charmap=0x7ffffe0d0640, repertoire_name=0x0,
ignore_content=<optimized out>) at programs/ld-ctype.c:2141
#13 0x000000001003c3ec in locfile_read (result=0x7fffffb35980,
charmap=0x7ffffe0d0640) at programs/locfile.c:173
#14 0x000000001000490c in load_locale (category=<optimized out>,
name=0x7fffffb35940 "nl_NL", repertoire_name=0x0, charmap=0x7ffffe0d0640,
copy_locale=0x0) at programs/localedef.c:621
#15 0x0000000010010c9c in ctype_read (ldfile=0x7ffffe0d0520,
result=0x7ffff5cbfef0, charmap=0x7ffffe0d0640, repertoire_name=0x0,
ignore_content=<optimized out>) at programs/ld-ctype.c:2141
#16 0x000000001003c3ec in locfile_read (result=0x7ffff5cbfef0,
charmap=0x7ffffe0d0640) at programs/locfile.c:173
#17 0x0000000010003720 in main (argc=<optimized out>, argv=0x7ffff5cc0520)
at programs/localedef.c:252
2763 {
2764 remainder_size = size - nb;
2765 remainder = chunk_at_offset (p, nb);
2766 av->top = remainder;
2767 set_head (p, nb | PREV_INUSE | (av != &main_arena ?
NON_MAIN_ARENA : 0));
2768 set_head (remainder, remainder_size | PREV_INUSE);
2769 check_malloced_chunk (av, p, nb);
2770 return chunk2mem (p);
2771 }
The fault happens here:
0x00007fffbe2af090 <+384>: xor r8,r30,r26
0x00007fffbe2af094 <+388>: subf r9,r31,r9
0x00007fffbe2af098 <+392>: addic r26,r8,-1
0x00007fffbe2af09c <+396>: ori r10,r31,1
0x00007fffbe2af0a0 <+400>: subfe r26,r26,r8
0x00007fffbe2af0a4 <+404>: add r31,r22,r31
0x00007fffbe2af0a8 <+408>: rldicr r26,r26,2,61
0x00007fffbe2af0ac <+412>: ori r9,r9,1
0x00007fffbe2af0b0 <+416>: or r26,r10,r26
0x00007fffbe2af0b4 <+420>: std r31,88(r30)
0x00007fffbe2af0b8 <+424>: addi r3,r22,16
0x00007fffbe2af0bc <+428>: std r26,8(r22)
=> 0x00007fffbe2af0c0 <+432>: std r9,8(r31)
Most variables have been optimized out, but:
remainder = 0x800000004800
r9 = 0x2b801
r31 = 0x800000004800
“info file” says this:
0x0000000010000000 - 0x0000000010010000 is load1a
0x0000000010010000 - 0x0000000010010000 is load1b
0x0000000010060000 - 0x0000000010070000 is load2
0x0000000010070000 - 0x0000000010080000 is load3
0x00007fffba840000 - 0x00007fffbbce0000 is load4
0x00007fffbcaf0000 - 0x00007fffbdf90000 is load5
0x00007fffbe1a0000 - 0x00007fffbe1a0000 is load6
0x00007fffbe1d0000 - 0x00007fffbe1d0000 is load7
0x00007fffbe1e0000 - 0x00007fffbe1e0000 is load8
0x00007fffbe1f0000 - 0x00007fffbe200000 is load9a
0x00007fffbe200000 - 0x00007fffbe200000 is load9b
0x00007fffbe3e0000 - 0x00007fffbe3e0000 is load10
0x00007fffbe3f0000 - 0x00007fffbe400000 is load11
0x00007fffbe400000 - 0x00007fffbe410000 is load12
0x00007fffbe410000 - 0x00007fffbe430000 is load13
0x00007fffbe430000 - 0x00007fffbe440000 is load14a
0x00007fffbe440000 - 0x00007fffbe440000 is load14b
0x00007fffbe470000 - 0x00007fffbe480000 is load15
0x00007fffbe480000 - 0x00007fffbe490000 is load16
0x00007ffff5ca0000 - 0x00007ffff5cd0000 is load17
0x00007ffffe0d0000 - 0x0000800000030000 is load18
So address appears to be above the top of the heap.
This glibc is based on 2.26. We've only seen this on ppc64 so far (not s390x).
--
You are receiving this mail because:
You are on the CC list for the bug.