Bug 859528

Summary: Segfault in esxutilstest test (from libvirt test suite) with latest glibc from Rawhide
Product: [Fedora] Fedora Reporter: Richard W.M. Jones <rjones>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: berrange, clalancette, itamar, jforbes, jyang, laine, libvirt-maint, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-22 01:25:26 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Richard W.M. Jones 2012-09-21 14:33:07 EDT
Description of problem:

This happened during a routine build of libvirt in Koji:

PASS: lxcxml2xmltest
TEST: openvzutilstest
      ..                                       2   OK
PASS: openvzutilstest
TEST: esxutilstest
      .../bin/sh: line 5: 25323 Segmentation fault      abs_top_builddir=`cd '..'; pwd` abs_top_srcdir=`cd '..'; pwd` abs_builddir=`pwd` abs_srcdir=`cd '.'; pwd` CONFIG_HEADER="`cd '..'; pwd`/config.h" PATH="`cd '..'; pwd`/daemon:`cd '..'; pwd`/tools:`cd '..'; pwd`/tests:$PATH" SHELL="/bin/sh" LIBVIRT_DRIVER_DIR="/builddir/build/BUILD/libvirt-0.10.1/src/.libs" LIBVIRT_AUTOSTART=0 LC_ALL=C ${dir}$tst
FAIL: esxutilstest
TEST: vmx2xmltest
      ........................................ 40 
      ..........                               50  OK
PASS: vmx2xmltest
TEST: xml2vmxtest


Version-Release number of selected component (if applicable):

libvirt 0.10.1

How reproducible:

Happened twice in Koji.  However it doesn't fail on my local machine.

Perhaps it's caused by some component in Rawhide, eg. glibc?
Comment 1 Richard W.M. Jones 2012-09-21 15:18:09 EDT
Fedora 18 build was successful.
Comment 2 Richard W.M. Jones 2012-09-21 15:22:56 EDT
I can reproduce this, and it seems to be caused by
upgrading glibc from glibc-2.16.90-11.fc19
to glibc-2.16.90-13.fc19.
Comment 3 Richard W.M. Jones 2012-09-21 15:31:29 EDT
Here is the stack trace.  It doesn't make a lot of sense to me.

Program terminated with signal 11, Segmentation fault.
#0  0x00007f7d018ac150 in __gconv_release_step (step=0x22f8b18)
    at gconv_db.c:224
224		  DL_CALL_FCT (end_fct, (step));
(gdb) bt
#0  0x00007f7d018ac150 in __gconv_release_step (step=0x22f8b18)
    at gconv_db.c:224
#1  0x00007f7d018ad0e4 in __gconv_close_transform (steps=0x22f8ab0, nsteps=2)
    at gconv_db.c:794
#2  0x00007f7d018ac079 in __gconv_close (cd=<optimized out>)
    at gconv_close.c:63
#3  0x00007f7d018ab58f in iconv_close (cd=<optimized out>) at iconv_close.c:35
#4  0x0000003d772335e7 in xmlCharEncCloseFunc () from /lib64/libxml2.so.2
#5  0x00007f7d0255dcd1 in virVMXConvertToUTF8 (
    encoding=encoding@entry=0x403705 "Windows-1252", string=<optimized out>)
    at vmx/vmx.c:626
#6  0x0000000000401c07 in testConvertWindows1252ToUTF8 (data=<optimized out>)
    at esxutilstest.c:237
#7  0x0000000000402cd0 in virtTestRun (
    title=title@entry=0x403ac8 "VMware ConvertWindows1252ToUTF8", 
    body=body@entry=0x401bd0 <testConvertWindows1252ToUTF8>, 
    data=data@entry=0x0) at testutils.c:160
#8  0x0000000000401b9e in mymain () at esxutilstest.c:274
#9  0x000000000040330b in virtTestMain (argc=1, argv=0x7fff7a910078, 
    func=0x401b10 <mymain>) at testutils.c:720
#10 0x00007f7d018aab85 in __libc_start_main (main=0x4019b0 <main>, argc=1, 
    ubp_av=0x7fff7a910078, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fff7a910068) at libc-start.c:258
#11 0x0000000000401a11 in _start ()

(gdb) print end_fct
$1 = (void (*)(struct __gconv_step *)) 0x77aefd53728fa10e
(gdb) print *end_fct
Cannot access memory at address 0x77aefd53728fa10e
(gdb) print step
$2 = (struct __gconv_step *) 0x22f8b18
(gdb) print *step
$3 = {__shlib_handle = 0x22f0420, __modname = 0x0, __counter = 0, 
  __from_name = 0x7f7d01a07daf "INTERNAL", 
  __to_name = 0x7f7d02bd7a21 <Address 0x7f7d02bd7a21 out of bounds>, 
  __fct = 0x45ce4424c9cef5d, __btowc_fct = 0x0, 
  __init_fct = 0x45ce4424f9cef5d, __end_fct = 0x0, __min_needed_from = 4, 
  __max_needed_from = 4, __min_needed_to = 1, __max_needed_to = 1, 
  __stateful = 0, __data = 0xffffffffffffffff}
Comment 4 Daniel Veillard 2012-09-22 01:18:56 EDT
The only way i could analyze that would be a change of behaviour of iconv
in the latest glibc version ... I wonder what's the diff between
  glibc-2.16.90-11 and glibc-2.16.90-13 ... probably worth looking at
any patch added in the meantime. I would guess the problem would also
show up using libxml2 regression testing, except if it's related to that
specific encoding (Windows-1252) then I doubt libxml2 exercises that
specific converter ...

Comment 5 Daniel Veillard 2012-09-22 01:25:26 EDT
* Fri Sep 21 2012 Jeff Law <law@redhat.com> - 2.16.90-14
  - Revert patch for 816647, it's blatently broken.

"glibc sometimes crashes in localization code"

okay, I'm nearly 100% sure it's a side effect of trying to fix this,


*** This bug has been marked as a duplicate of bug 816647 ***
Comment 6 Richard W.M. Jones 2012-09-22 03:36:08 EDT
This was a glibc bug in the -13 package.  Fixed by
upgrading to -14.  See: