On Mon, Sep 29, 2014 at 00:32:45 -0400, Jon DeVree wrote:
> I have this and poked around monitoring everything while it happened
> repeatedly. I stumbled onto a reliable means of reproduction:
>
> dig -t AAAA ocsp.verisign.net.
>
> Happens with dnssec enable and disabled, so its not that. I tried it
> with a pretty stripped down to the original bind config and it still
> happened.
>
> https://www.cloudshark.org/captures/56802b91286a
>
> Its presumably the reply from verisign that kills it, but I'm not sure
> why.
I built a copy with -g and put it on a fresh box with the default
config:
(gdb) bt
#0 0x00007f791c858077 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f791c859458 in __GI_abort () at abort.c:89
#2 0x00007f791f371939 in assertion_failed ()
#3 0x00007f791d56551a in isc_assertion_failed (file=<optimized out>,
line=<optimized out>, type=<optimized out>, cond=<optimized out>) at
assertions.c:57
#4 0x00007f791d575d6b in isc___mem_put (ctx0=0x7f79101374d0, ptr=0x0,
size=140158116788496, file=0x0, line=394956816) at mem.c:1321
#5 0x00007f791ec22d04 in dns_rdataslab_fromrdataset (rdataset=0x7f791ac37910,
mctx=0x7f79101374d0, region=0x7f791ac374d0, reservelen=<optimized out>) at
rdataslab.c:334
#6 0x00007f791ebd0c3a in addrdataset (db=0x7f79178a9010, node=0x665f,
version=0x6, now=1412002148, rdataset=0x7f791ac37910, options=134349840,
addedrdataset=0x7f791f16d160) at rbtdb.c:6466
#7 0x00007f791ebb7e04 in addoptout (message=0x665e, cache=0x665f, node=0x6,
covers=65535, now=0, minttl=134349840, maxttl=449018128,
optout=isc_boolean_false, secure=isc_boolean_false,
addedrdataset=0x7f791f16d160) at ncache.c:272
#8 0x00007f791ebb7f69 in dns_ncache_add (message=<optimized out>,
cache=<optimized out>, node=<optimized out>, covers=<optimized out>,
now=<optimized out>, minttl=<optimized out>, maxttl=10800,
addedrdataset=0x7f791f16d160) at ncache.c:105
#9 0x00007f791ec29ced in ncache_adderesult (message=0x7f79176201d8,
cache=0x665f, node=0x6, covers=65535, now=0, minttl=134349840, maxttl=10800,
optout=isc_boolean_false, secure=isc_boolean_false, ardataset=0x7f791f16d160,
eresultp=0x7f791ac38e48) at resolver.c:5012
#10 0x00007f791ec38010 in validated (task=0x665e, event=0x7f791f30b968) at
resolver.c:4208
#11 0x00007f791d5860fb in dispatch (manager=0x7f791f2de010) at task.c:1116
#12 run (uap=0x7f791f2de010) at task.c:1286
#13 0x00007f791cf380a4 in start_thread (arg=0x7f791ac39700) at
pthread_create.c:309
#14 0x00007f791c908c2d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Line 334 of rdataslab.c is this:
if (x != NULL)
isc_mem_put(mctx, x, nalloc * sizeof(struct xrdata));
Rebuilding rdataslab.c with -O1 instead of -O2 and the problem goes away.
Rebuilding rdataslab.c with GCC-4.8 instead of GCC-4.9 and it goes away too.
(Anyone reading this who knows how the optimizer works can probably stop
reading now... its exactly what you think. Took me a minute to find the
exact problematic location even after this though.)
Certain actions will promise the compiler that x can't be NULL, like
dereferencing it. Which would allow the compiler to optimize the NULL
check away, but all the dereferences are surrounded by checks so they
only happen when x can't be NULL.
Except that call to qsort(), which is decorated in the libc headers with
__nonnull. I can only presume that this is telling the compiler exactly
what I think it does because surrounding the call to qsort on line 197
with a check fixes everything. Likewise, just removing the __nonnull
decoration from the qsort definition fixes it too.
--
Jon
Kernel Archaeologist
X(7): A program for managing terminal windows. See also screen(1).
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
