It build fine in F17

http://koji.fedoraproject.org/koji/taskinfo?taskID=4418563

This is weird, I can reproduce it in koji but cannot in local mock build...

any update on this? It's preventing me from releasing a CVE for unbound :(

I have the same issue, it builds fine locally

(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.

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

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.

re-assigning to glibc

Do y'all have a core file I can look at?

http://kevin.fedorapeople.org/core.17939

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.

Fixed in swig-2.0.8-1.fc19