Crash in gconv_db.c

[Abhidnya Joshi <abhidnyachirmule@gmail.com>]

Hi,

We use glibc version glibc-2.17-78.el7.src.rpm on centos.

We encountered a problem recently in our product where we get crash in
libc stack in gconv.
The crash is seen randomly after few days during character encoding
(UTF-8 to UTF-16LE). The functions getting called are:

iconv_open --> __gconv_open--> __gconv_find_transform -->
find_derivation --> increment_counter

In increment_counter, we get nstep = 2. In the second iteration inside
increment_counter when step[0] is under processing,
we see below values in it:
shlib_handle is NULL, _modname = NULL, __counter = 1 after condition
check in (increment-counter), from_name UTF-8 to to_name INTENAL

{__shlib_handle = 0x0, __modname = 0x0, __counter = 1, __from_name =
0x7f028853b890 "ISO-10646/UTF8/", __to_name = 0x7f028abca431
"INTERNAL",
  __fct = 0x7f028aa73ce0 <__gconv_transform_utf8_internal>,
__btowc_fct = 0x7f028aa714b0 <__gconv_btwoc_ascii>, __init_fct = 0x0,
__end_fct = 0x0, __min_needed_from = 1,
  __max_needed_from = 6, __min_needed_to = 4, __max_needed_to = 4,
__stateful = 0, __data = 0x0}


The stack looks something like this:

(gdb) bt
#0  0x00007f028aa6f31a in increment_counter (nsteps=2,
steps=0x7f028853b140) at gconv_db.c:393
#1  find_derivation (toset=toset@entry=0x7f0251ceb990 "UTF-16LE//",
toset_expand=0x0, fromset=fromset@entry=0x7f0251ceb970 "UTF-8//",
    fromset_expand=fromset_expand@entry=0x7f028853a798
"ISO-10646/UTF8/", handle=handle@entry=0x7f0251ceb900,
nsteps=nsteps@entry=0x7f0251ceb910) at gconv_db.c:426
#2  0x00007f028aa6ff61 in __gconv_find_transform
(toset=toset@entry=0x7f0251ceb990 "UTF-16LE//",
fromset=fromset@entry=0x7f0251ceb970 "UTF-8//",
handle=handle@entry=0x7f0251ceb900,
    nsteps=nsteps@entry=0x7f0251ceb910, flags=flags@entry=0) at gconv_db.c:755
#3  0x00007f028aa6e7ea in __gconv_open
(toset=toset@entry=0x7f0251ceb990 "UTF-16LE//",
fromset=fromset@entry=0x7f0251ceb970 "UTF-8//",
handle=handle@entry=0x7f0251ceb9c0,
    flags=flags@entry=0) at gconv_open.c:173
#4  0x00007f028aa6e371 in iconv_open (tocode=0x7f0251ceb990
"UTF-16LE//", fromcode=0x7f0251ceb970 "UTF-8//") at iconv_open.c:71

(Pasting last 4 frames out of 27)

The gconv_steps looked like below:

(gdb) p *(&step[1])
$4 = {__shlib_handle = 0x7f028853b240, __modname = 0x7f028853b270
"/usr/lib64/gconv/UTF-16.so", __counter = 1, __from_name =
0x7f028abca431 "INTERNAL",
  __to_name = 0x7f028853b220 "UTF-16LE//", __fct = 0x59e0be5c0391534f,
__btowc_fct = 0xa7e5bbe252f1534f, __init_fct = 0x59e0be5c1c91534f,
__end_fct = 0x59e0be5c03b1534f,
  __min_needed_from = 4, __max_needed_from = 4, __min_needed_to = 2,
__max_needed_to = 4, __stateful = 0, __data = 0x9bd320}
(gdb) p *(&step[0])
$5 = {__shlib_handle = 0x0, __modname = 0x0, __counter = 1,
__from_name = 0x7f028853b890 "ISO-10646/UTF8/", __to_name =
0x7f028abca431 "INTERNAL",
  __fct = 0x7f028aa73ce0 <__gconv_transform_utf8_internal>,
__btowc_fct = 0x7f028aa714b0 <__gconv_btwoc_ascii>, __init_fct = 0x0,
__end_fct = 0x0, __min_needed_from = 1,
  __max_needed_from = 6, __min_needed_to = 4, __max_needed_to = 4,
__stateful = 0, __data = 0x0}
(gdb)

And locals were:
(gdb) f 0
#0  0x00007f028aa6f31a in increment_counter (nsteps=2,
steps=0x7f028853b140) at gconv_db.c:393
393     in gconv_db.c
(gdb) info locals
init_fct = 0xa9a7d3f2ddf12978
step = 0x7f028853b140
cnt = 0
result = 0
(gdb)

Coming back to the core, if we examine frame 0, it gave problem at
below assembly code:

   0x00007f028aa6f2e1 <+209>:   mov    0x20(%rax),%r15
   0x00007f028aa6f2e5 <+213>:   mov    0x28(%rax),%rax
   0x00007f028aa6f2e9 <+217>:   movq   $0x0,0x30(%rbx)
   0x00007f028aa6f2f1 <+225>:   mov    %rdx,0x28(%rbx)
   0x00007f028aa6f2f5 <+229>:   mov    %r15,0x38(%rbx)
   0x00007f028aa6f2f9 <+233>:   mov    %rax,0x40(%rbx)
   0x00007f028aa6f2fd <+237>:   ror    $0x11,%r15
   0x00007f028aa6f301 <+241>:   xor    %fs:0x30,%r15
   0x00007f028aa6f30a <+250>:   test   %r15,%r15
   0x00007f028aa6f30d <+253>:   je     0x7f028aa6f332 <find_derivation+290>
   0x00007f028aa6f30f <+255>:   mov    %r15,%rdi
   0x00007f028aa6f312 <+258>:   callq  0x7f028ab7f7b0
<__GI__dl_mcount_wrapper_check>
   0x00007f028aa6f317 <+263>:   mov    %rbx,%rdi
=> 0x00007f028aa6f31a <+266>:   callq  *%r15
   0x00007f028aa6f31d <+269>:   mov    0x30(%rbx),%rax
   0x00007f028aa6f321 <+273>:   xor    %fs:0x30,%rax
   0x00007f028aa6f32a <+282>:   rol    $0x11,%rax
   0x00007f028aa6f32e <+286>:   mov    %rax,0x30(%rbx)
   0x00007f028aa6f332 <+290>:   sub    $0x1,%r12
   0x00007f028aa6f336 <+294>:   sub    $0x68,%rbx
   0x00007f028aa6f33a <+298>:   test   %r12,%r12
   0x00007f028aa6f33d <+301>:   je     0x7f028aa6f35f <find_derivation+335>


The questions here are:
1. why step[0] has counter 1? this means it was 0, got incremented via
increment_counter and hence getting inside

              DL_CALL_FCT (init_fct, (step));

2. When step gets initialized, counter is never 0. Under which
condition this can become 0?
3. Please let me know what to debug more to understand this.

Thanks
Abhidnya