TCP and NSSEARCH = Core Dump

Thu Nov 28 11:57:03 UTC 2013

We'll open a bug for this.
Thanks
Sue
On 11/28/2013 3:47 AM, Joshua Rogers wrote:
> After testing a little bit more, I've found that it is partially fixed
> in bind-9.10.0a1.
>
> I was using bind 9.8.1-P1 in the original snippets. - So that's
> outdated I guess.
>
> So I hope you can follow these 'logs'... This explains it more indepth
> in the latest version of bind[9.10.0a1]
>
> 22:38:16 (root at SWAN) /var/tmp/bind-9.10.0a1/bin/dig # dig -v
> DiG 9.8.1-P1
> 22:38:17 (root at SWAN) /var/tmp/bind-9.10.0a1/bin/dig # ./dig -v
> DiG 9.10.0a1
> 22:38:18 (root at SWAN) /var/tmp/bind-9.10.0a1/bin/dig # dig +tcp
> +nssearch  tynyturi.com
> socket.c:2535: REQUIRE(socketp != ((void *)0) && *socketp == ((void
> *)0)) failed, back trace
> #0 0x7fb662acf563 in ??
> #1 0x7fb662acf4ca in ??
> #2 0x7fb662afbef8 in ??
> #3 0x7fb663912d19 in ??
> #4 0x7fb6639130be in ??
> #5 0x7fb662aee6c8 in ??
> #6 0x7fb6628ade9a in ??
> #7 0x7fb6625da3fd in ??
> Aborted (core dumped)
> 22:39:01 (root at SWAN) /var/tmp/bind-9.10.0a1/bin/dig # ./dig +tcp
> +nssearch tynyturi.com
> SOA v1s1.xundns.com. nsadmin.xundns.com. 50845 3600 600 604800 600
> from server 60.174.233.164 in 256 ms.
> SOA v1s1.xundns.com. nsadmin.xundns.com. 50845 3600 600 604800 600
> from server 121.10.104.50 in 263 ms.
> SOA v1s1.xundns.com. nsadmin.xundns.com. 50845 3600 600 604800 600
> from server 60.214.139.75 in 268 ms.
> SOA v1s1.xundns.com. nsadmin.xundns.com. 50845 3600 600 604800 600
> from server 59.63.181.21 in 288 ms.
> SOA v1s1.xundns.com. nsadmin.xundns.com. 50845 3600 600 604800 600
> from server 222.163.192.23 in 330 ms.
> SOA v1s1.xundns.com. nsadmin.xundns.com. 50845 3600 600 604800 600
> from server 59.63.165.131 in 450 ms.
>
> From here, it just freezes, and you have to control z to get out of
> it. You can't control C.
>
> So, it seems that +tcp and +nssearch combined is [partially] fixed, I
> guess.
> But it stills hangs nonetheless.
>
>
> Next.. If we just run
> "./dig  +nssearch tynyturi.com" a few times(bind 9.10.0a1), we get..
>  # ./dig  +nssearch tynyturi.com
> SOA v1s1.xundns.com. nsadmin.xundns.com. 50845 3600 600 604800 600
> from server 59.63.165.131 in 246 ms.
> SOA v1s1.xundns.com. nsadmin.xundns.com. 50845 3600 600 604800 600
> from server 60.214.139.75 in 273 ms.
> SOA v1s1.xundns.com. nsadmin.xundns.com. 50845 3600 600 604800 600
> from server 59.63.181.21 in 295 ms.
> ;; Truncated, retrying in TCP mode.
> SOA v1s1.xundns.com. nsadmin.xundns.com. 50845 3600 600 604800 600
> from server 59.63.165.131 in 256 ms.
> SOA v1s1.xundns.com. nsadmin.xundns.com. 50845 3600 600 604800 600
> from server 59.63.181.21 in 266 ms.
> SOA v1s1.xundns.com. nsadmin.xundns.com. 50845 3600 600 604800 600
> from server 60.214.139.75 in 286 ms.
> SOA v1s1.xundns.com. nsadmin.xundns.com. 50845 3600 600 604800 600
> from server 121.10.104.50 in 431 ms.
> SOA v1s1.xundns.com. nsadmin.xundns.com. 50845 3600 600 604800 600
> from server 60.174.233.164 in 464 ms.
>
>
> Don't ask me why it transfers to TCP mode. I don't know why.
>
>
> So, it seems that when in TCP mode, you can't use nssearch without it
> either 1) crashing[in older versions], or 2) hanging forever[in newer
> versions].
>
>
> And one more bug..
> When using TCP mode, if you control-c before it's finished[but it has
> atleast started], it will core dump.
> Examples:
>  # ./dig  +nssearch +tcp tynyturi.com
> ^Csocket.c:4768: REQUIRE(task != ((void *)0)) failed, back trace
> #0 0x561799 in ??
> #1 0x5618fa in ??
> #2 0x596ce9 in ??
> #3 0x41419a in ??
> #4 0x416865 in ??
> #5 0x582444 in ??
> #6 0x7f7e1dec4e9a in ??
> #7 0x7f7e1d8953fd in ??
> Aborted (core dumped)
>
>
>
>
> I hope that all makes sense..
> If it doesn't, please let me know.
>
>
>
> Thanks
>
>
>
>
>
>
> *Joshua Rogers* - gpg pubkey
> <http://www.internot.info/docs/gpg_pubkey.asc.gpg>
> "The system's for sale"
> On 28/11/13 22:21, Joshua Rogers wrote:
>> Hi everyone.
>>
>> I'm unsure of the email I should be writing to, but I chose this one;
>>
>>
>> I've just found a segfault/core dump bug in dig.
>>
>> Running a dig command with +nssearch and +tcp will cause dig to
>> coredump..
>>
>> Example:
>> --snip--
>>
>> $ dig +time=3 +nssearch +tcp google.com
>> socket.c:2535: REQUIRE(socketp != ((void *)0) && *socketp == ((void
>> *)0)) failed, back trace
>> #0 0xb3f77b in ??
>> #1 0xb3f6c4 in ??
>> #2 0xb72062 in ??
>> #3 0xd1d3ef in ??
>> #4 0xd1d7c3 in ??
>> #5 0xb629ac in ??
>> #6 0x972d4c in ??
>> #7 0x55bbae in ??
>> Aborted (core dumped)
>>
>> --/snip--
>>
>>
>> It was discovered whilst running "dig +time=3 +nssearch
>> tynyturi.com", which [sometimes] dumps.
>> --
>> SOA v1s1.xundns.com. nsadmin.xundns.com. 50845 3600 600 604800 600
>> from server 121.10.104.50 in 258 ms.
>> SOA v1s1.xundns.com. nsadmin.xundns.com. 50845 3600 600 604800 600
>> from server 59.63.165.131 in 260 ms.
>> SOA v1s1.xundns.com. nsadmin.xundns.com. 50845 3600 600 604800 600
>> from server 59.63.181.21 in 261 ms.
>> SOA v1s1.xundns.com. nsadmin.xundns.com. 50845 3600 600 604800 600
>> from server 60.174.233.164 in 271 ms.
>> ;; Truncated, retrying in TCP mode.
>> socket.c:2535: REQUIRE(socketp != ((void *)0) && *socketp == ((void
>> *)0)) failed, back trace
>> #0 0x29877b in ??
>> #1 0x2986c4 in ??
>> #2 0x2cb062 in ??
>> #3 0xb8a3ef in ??
>> #4 0xb8a7c3 in ??
>> #5 0x2bb9ac in ??
>> #6 0x828d4c in ??
>> #7 0x92cbae in ??
>> Aborted (core dumped)
>>
>> --
>>
>>
>> And finally, gdb output:
>>
>>
>> --snip--
>> Starting program: /usr/bin/dig +time=3 +nssearch +tcp tynyturi.com
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
>> [New Thread 0xb7f93b40 (LWP 10758)]
>> [New Thread 0xb7792b40 (LWP 10759)]
>> [New Thread 0xb6f91b40 (LWP 10760)]
>> socket.c:2535: REQUIRE(socketp != ((void *)0) && *socketp == ((void
>> *)0)) failed, back trace
>> #0 0x31977b in ??
>> #1 0x3196c4 in ??
>> #2 0x34c062 in ??
>> #3 0x8000d3ef in ??
>> #4 0x8000d7c3 in ??
>> #5 0x33c9ac in ??
>> #6 0x371d4c in ??
>> #7 0x475bae in ??
>>
>> Program received signal SIGABRT, Aborted.
>> [Switching to Thread 0xb7f93b40 (LWP 10758)]
>> 0x00132416 in __kernel_vsyscall ()
>> (gdb) backtrace
>> #0  0x00132416 in __kernel_vsyscall ()
>> #1  0x003b41df in raise () from /lib/i386-linux-gnu/libc.so.6
>> #2  0x003b7825 in abort () from /lib/i386-linux-gnu/libc.so.6
>> #3  0x003196c9 in isc_assertion_failed () from /usr/lib/libisc.so.83
>> #4  0x0034c062 in isc__socket_create () from /usr/lib/libisc.so.83
>> #5  0x8000d3ef in ?? ()
>> #6  0x8000d7c3 in ?? ()
>> #7  0x0033c9ac in ?? () from /usr/lib/libisc.so.83
>> #8  0x00371d4c in start_thread () from
>> /lib/i386-linux-gnu/libpthread.so.0
>> #9  0x00475bae in clone () from /lib/i386-linux-gnu/libc.so.6
>> --/snip--
>>
>>
>> Hopefully this information is useful :)
>>
>>
>>
>> Thanks,
>> -- 
>> *Joshua Rogers* - gpg pubkey
>> <http://www.internot.info/docs/gpg_pubkey.asc.gpg>
>> "The system's for sale"
>
>
>
> _______________________________________________
> bind-workers mailing list
> bind-workers at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-workers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/mailman/private/bind-workers/attachments/20131128/9d30eeef/attachment.html>