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 [...] http://kojipkgs.fedoraproject.org//work/tasks/1944/4511944/build.log http://kojipkgs.fedoraproject.org//work/tasks/1991/4511991/build.log 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?
Fedora 18 build was successful.
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.
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", nloops=nloops@entry=1, 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}
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 ... Daniel
* Fri Sep 21 2012 Jeff Law <law> - 2.16.90-14 - Revert patch for 816647, it's blatently broken. https://bugzilla.redhat.com/show_bug.cgi?id=816647 "glibc sometimes crashes in localization code" okay, I'm nearly 100% sure it's a side effect of trying to fix this, Daniel *** This bug has been marked as a duplicate of bug 816647 ***
This was a glibc bug in the -13 package. Fixed by upgrading to -14. See: https://lists.fedoraproject.org/pipermail/devel/2012-September/thread.html#171786