Bug 851364 - swig segfaults on fedora build systems when building unbound
swig segfaults on fedora build systems when building unbound
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: swig (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-23 19:19 EDT by Paul Wouters
Modified: 2013-04-30 19:52 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-12 10:04:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul Wouters 2012-08-23 19:19:10 EDT
Description of problem:
See: http://kojipkgs.fedoraproject.org//work/tasks/8307/4418307/build.log

dmesg of the build machine showed:

swig[9177]: segfault at 2633ff8 ip 00007fd2d89c467b sp 00007fff9f50b2d8 error 4 in libc-2.16.90.so[7fd2d8933000+1b6000]


Version-Release number of selected component (if applicable):
2.0.7-4.fc18

How reproducible:
Issueing fedpkg it burns and dies. but building on a test f18 it worked.

Steps to Reproduce:
1. grab latest srpm from unbound master branch and try to build


See full build info: http://koji.fedoraproject.org/koji/taskinfo?taskID=4418307
Comment 1 Paul Wouters 2012-08-23 19:44:18 EDT
It build fine in F17

http://koji.fedoraproject.org/koji/taskinfo?taskID=4418563
Comment 2 Adam Tkac 2012-08-24 05:05:01 EDT
This is weird, I can reproduce it in koji but cannot in local mock build...
Comment 3 Paul Wouters 2012-09-05 13:32:46 EDT
any update on this? It's preventing me from releasing a CVE for unbound :(

I have the same issue, it builds fine locally
Comment 4 Adam Tkac 2012-09-06 05:36:06 EDT
(In reply to comment #3)
> any update on this? It's preventing me from releasing a CVE for unbound :(

It shouldn't be so big issue because this affects only F19...

> I have the same issue, it builds fine locally

There are two weird things:

1. i686 build passed yesterday (https://kojiweb.fedoraproject.org/koji/taskinfo?taskID=4453130)
2. Exactly same version of swig is in F18 and everything works fine.

I'm trying to figure what's going on, stay tuned.
Comment 5 Tom "spot" Callaway 2012-09-06 11:57:31 EDT
I think this is F19 specific, the core bt implies it might be glibc to blame:

Core was generated by `/usr/bin/swig -python -o libunbound/python/libunbound_wrap.c -I. -I/usr/include'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007ff07b35c3a7 in __memmove_ssse3 () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ff07b35c3a7 in __memmove_ssse3 () from /lib64/libc.so.6
#1  0x000000000041f914 in memmove (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>)
    at /usr/include/bits/string3.h:57
#2  replace_simple (match=<optimized out>, count=25975336, flags=<optimized out>, rep=0x5436e8 "", 
    token=<optimized out>, str=0x18c5860) at DOH/string.c:787
#3  replace_simple (str=0x18c5860, token=<optimized out>, rep=0x5436e8 "", flags=<optimized out>, 
    count=25975336, match=<optimized out>) at DOH/string.c:675
#4  0x0000000000500be7 in manglestr_default (s=<optimized out>) at Swig/stype.c:1086
#5  SwigType_manglestr (s=s@entry=0x7ff07b10f590) at Swig/stype.c:1133
#6  0x000000000050e516 in SwigType_remember_clientdata (t=t@entry=0x7ff07b10f590, 
    clientdata=clientdata@entry=0x0) at Swig/typesys.c:1479
#7  0x000000000050e6f7 in SwigType_remember (ty=ty@entry=0x7ff07b10f590) at Swig/typesys.c:1562
#8  0x0000000000508b54 in typemap_replace_vars (s=s@entry=0x7ff07b110db0, locals=locals@entry=0x0, 
    type=type@entry=0x7ff07b10f590, rtype=rtype@entry=0x7ff07b10f590, pname=pname@entry=0x7ff07b10f5d0, 
    lname=lname@entry=0x7ff07b10e6f0, index=index@entry=1) at Swig/typemap.c:1028
#9  0x000000000050a279 in Swig_typemap_attach_parms (tmap_method=0x530b21, parms=<optimized out>, f=0x0)
    at Swig/typemap.c:1736
#10 0x0000000000451b12 in emit_attach_parmmaps (l=0x7ff07b10edd0, f=0x18c46a0) at Modules/emit.cxx:108
#11 0x00000000004bf352 in PYTHON::functionWrapper (this=0x1264b20, n=0x7ff07b194190)
    at Modules/python.cxx:2065
#12 0x000000000047e178 in Language::membervariableHandler (this=0x1264b20, n=0x7ff07b194190)
    at Modules/lang.cxx:1478
#13 0x00000000004b3048 in PYTHON::membervariableHandler (this=0x1264b20, n=0x7ff07b194190)
    at Modules/python.cxx:4298
#14 0x000000000047947f in Language::variableHandler (this=0x1264b20, n=0x7ff07b194190)
    at Modules/lang.cxx:1357
#15 0x000000000047f8ab in Language::cDeclaration (this=0x1264b20, n=0x7ff07b194190)
    at Modules/lang.cxx:1013
#16 0x000000000047b3d0 in Dispatcher::emit_one (this=this@entry=0x1264b20, n=n@entry=0x7ff07b194190)
    at Modules/lang.cxx:121
#17 0x000000000047c0de in emit_one (n=0x7ff07b194190, this=0x1264b20) at Modules/lang.cxx:377
#18 Language::emit_one (this=0x1264b20, n=0x7ff07b194190) at Modules/lang.cxx:354
#19 0x000000000047b01d in Dispatcher::emit_children (this=0x1264b20, n=<optimized out>)
    at Modules/lang.cxx:212
#20 0x0000000000478b5e in Language::classHandler (this=0x1264b20, n=0x7ff07b1930d0)
    at Modules/lang.cxx:2452
#21 0x00000000004c393b in PYTHON::classHandler (this=0x1264b20, n=0x7ff07b1930d0)
    at Modules/python.cxx:3748
#22 0x000000000047c750 in classDeclaration (n=<optimized out>, this=0x1264b20) at Modules/lang.cxx:2423

...

The only obvious glibc memmove change between F-18 and F-19 is:

http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=9a0a54864bc015efbbbd15dcf365bcb2c147fb90
Comment 6 Tom "spot" Callaway 2012-09-06 11:59:39 EDT
Sorry, wrong bt, this is a different one:

#0  __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:834
834		movaps	%xmm1, -0x10(%rdi)
(gdb) bt
#0  __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:834
#1  0x000000000041f914 in memmove (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>)
    at /usr/include/bits/string3.h:57

The rest is identical.
Comment 7 Paul Wouters 2012-09-06 12:24:48 EDT
re-assigning to glibc
Comment 8 Jeff Law 2012-09-06 13:27:55 EDT
Do y'all have a core file I can look at?
Comment 9 Tom "spot" Callaway 2012-09-06 15:16:14 EDT
http://kevin.fedorapeople.org/core.17939
Comment 10 Jeff Law 2012-09-07 15:15:14 EDT
This is a swig problem of some sort.

Set up a rawhide mock environment and install the glibc, glibc-common and swig debuginfos.  Then

gdb /usr/bin/swig core.17939 
GNU gdb (GDB) Fedora (7.4.91.20120801-17.fc18)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/swig...Reading symbols from /usr/lib/debug/usr/bin/swig.debug...done.
done.
[New LWP 17939]
Core was generated by `/usr/bin/swig -python -o libunbound/python/libunbound_wrap.c -I. -I/usr/include'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007ff07b35c3a7 in __memmove_ssse3 () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install libgcc-4.7.1-7.fc19.x86_64 libstdc++-4.7.1-7.fc19.x86_64 pcre-8.31-2.fc19.x86_64
(gdb) up
#1  0x000000000041f914 in memmove (__len=<optimized out>, __src=<optimized out>, 
    __dest=<optimized out>) at /usr/include/bits/string3.h:57
warning: Source file is more recent than executable.
57        return __builtin___memmove_chk (__dest, __src, __len, __bos0 (__dest));
(gdb) up
#2  replace_simple (match=<optimized out>, count=25975336, flags=<optimized out>, rep=0x5436e8 "", 
    token=<optimized out>, str=0x18c5860) at DOH/string.c:787
787           memmove(t, s, (str->str + str->len) - s + 1);
(gdb) p (str->str + str->len) - s + 1
$1 = -7

(gdb) p/x $1
$2 = 0xfffffffffffffff9


So we're passing a totally bogus length to memmove.

The source string is:
(gdb) p s
$8 = 0x18c5a28 "ct ub_result"

Now looking at the fault we have:
(gdb) x/i $pc
=> 0x7ff07b35c3a7 <__memmove_ssse3+10311>:      movdqu 0x40(%rsi),%xmm4

(gdb) p/x $rsi
$6 = 0x18cffbe
(gdb) p/x $rsi + 0x40
$7 = 0x18cfffe

As you can see $rsi is tracking the source of the memmove.  We're in an unrolled block copy and $rsi+ 0x40 will load from a new page, which happens not to have a mapping (0x18d0000):

(gdb) x/x 0x18d0000
0x18d0000:      Cannot access memory at address 0x18d0000


Reassigning back to the swig team as the length passed to memmove is totally bogus.
Comment 11 Adam Tkac 2012-09-12 10:04:59 EDT
Fixed in swig-2.0.8-1.fc19

Note You need to log in before you can comment on or make changes to this bug.