From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69545 invoked by alias); 11 Nov 2019 16:05:35 -0000 Mailing-List: contact libc-locales-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-locales-owner@sourceware.org Received: (qmail 69530 invoked by uid 89); 11 Nov 2019 16:05:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-io1-f53.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=JZZMZLYPRxqV/Z4IPzP31zZIeHZiCtfpvRVSATJPyKs=; b=UkF4vNlG+k4hevhz0yIY5R/0WDMrIPoU5+6xFA3DH1TObbqRjhGXaA8Ftu7PYrg0Ow DU9hbRn7eVDTlbJnSzlyi9eq5+8tG0kjHOW7SGXisYj2VDQxSyxabahn0oJND9flBPxJ KnG6NR1Mx75qpjQ71jg8qSEx5QEOdZ9Si0102eaxr4IP7OmSWugM3x/D6SNJBvhWGeU/ C3Xp1iQveGnnUXp5WRsaTFJ58euBEE291yiLyWlyl2rBpi1Kt02DUTWFH4IerMP68zyv syAdy0n+S+mzVh6YR6fajIpjf3DZlv4t0FRmqtWqe8LZwA7PVWGFSmz3FyEtm7ygBsdQ d6XQ== MIME-Version: 1.0 From: Abhidnya Joshi Date: Mon, 11 Nov 2019 16:05:00 -0000 Message-ID: Subject: Crash in gconv_db.c To: libc-locales@sourceware.org Cc: abhidnya chirmule Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-q4/txt/msg00061.txt.bz2 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 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 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