bind 9.4.0 exit unexpectly with core dump

Sat Apr 7 23:51:53 UTC 2007

make that bind9-bugs at isc.org

> Thanks Stefan pointing me to the right direction. Here we go the right gdb.He
> lp me walk through the debugging.
> 
> I really appreciate it.
> 
> Regards,
> 
> shiling
> 
> [root at iamdying named]# gdb /usr/local/sbin/named core.9493
> GNU gdb Red Hat Linux (6.3.0.0-1.132.EL3rh)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db 
> library "/lib/tls/libthread_db.so.1".
> 
> Core was generated by `/usr/local/sbin/named'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /lib/libcrypto.so.4...done.
> Loaded symbols for /lib/libcrypto.so.4
> Reading symbols from /lib/libnsl.so.1...done.
> Loaded symbols for /lib/libnsl.so.1
> Reading symbols from /lib/tls/libc.so.6...done.
> Loaded symbols for /lib/tls/libc.so.6
> Reading symbols from /usr/kerberos/lib/libgssapi_krb5.so.2...done.
> Loaded symbols for /usr/kerberos/lib/libgssapi_krb5.so.2
> Reading symbols from /usr/kerberos/lib/libkrb5.so.3...done.
> Loaded symbols for /usr/kerberos/lib/libkrb5.so.3
> Reading symbols from /usr/kerberos/lib/libcom_err.so.3...done.
> Loaded symbols for /usr/kerberos/lib/libcom_err.so.3
> Reading symbols from /usr/kerberos/lib/libk5crypto.so.3...done.
> Loaded symbols for /usr/kerberos/lib/libk5crypto.so.3
> Reading symbols from /lib/libresolv.so.2...done.
> Loaded symbols for /lib/libresolv.so.2
> Reading symbols from /lib/libdl.so.2...done.
> Loaded symbols for /lib/libdl.so.2
> Reading symbols from /usr/lib/libz.so.1...done.
> Loaded symbols for /usr/lib/libz.so.1
> Reading symbols from /lib/ld-linux.so.2...done.
> Loaded symbols for /lib/ld-linux.so.2
> #0  0x080ae7cd in dns_message_totext (msg=0x4100c320, style=0x8189454, 
>     flags=0, target=0xbfff8410) at message.c:3133
> 3133                    ADD_STRING(target, rcodetext[msg->rcode]);
> (gdb) backtrace
> #0  0x080ae7cd in dns_message_totext (msg=0x4100c320, style=0x8189454, 
>     flags=0, target=0xbfff8410) at message.c:3133
> #1  0x0810ed1c in log_packet (message=0x4100c320, level=10, mctx=0x84970e8)
>     at resolver.c:5309
> #2  0x0810f47d in resquery_response (task=0xb75b8cc0, event=0xbfff84b8)
>     at resolver.c:5497
> #3  0x0816952e in dispatch (manager=0xb75af0f8) at task.c:867
> #4  0x08169bb6 in isc__taskmgr_dispatch () at task.c:1257
> #5  0x0816b76b in evloop () at app.c:357
> #6  0x0816ba1e in isc_app_run () at app.c:549
> #7  0x08058131 in main (argc=1, argv=0xbfff9a24) at main.c:868
> (gdb) 
> 
> 
> List:       bind-users
> Subject:    Re: bind 9.4.0 exit unexpectly with core dump
> From:       "Stefan Puiu" <stefan.puiu () gmail ! com>
> Date:       2007-04-07 14:49:05
> Message-ID: 775f04010704070749kd668189s808ab9936302080a () mail ! gmail ! com
> [Download message RAW]
> 
> try 'gdb /usr/local/sbin/named core.9493' - you need to specify the
> binary from which to read symbols from. If you've compiled bind from
> source with default options (it looks like it, since it's installed in
> /usr/local), the binary should have some debugging information (IIRC
> it's built with '-O2 -g' - both optimizations and some debug info).
> 
> Then, use 'bt' or 'backtrace' to see where the crash occured. 'trace'
> is something else, it won't help here.
> 
> HTH,
> Stefan
> 
> 
> 
> 
> 
> -----Original Message-----
> From: bind-users-bounce at isc.org on behalf of Ding, Shiling
> Sent: Sat 4/7/2007 10:01 AM
> To: bind-users at isc.org
> Subject: bind 9.4.0 exit unexpectly with core dump
>  
> We are running bind 9.4.0 on both our master and slave DNS servers, they are 
> all RHEL. Recently, both named has been core dump after running about 2 weeks
> , the memory usage is about 600M. I checked into the core dump, it's wired an
> d no trace available as following:
> 
>  [root at iamdying named]# gdb -core core.9493 
> GNU gdb Red Hat Linux (6.3.0.0-1.132.EL3rh)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-redhat-linux-gnu".
> Core was generated by `/usr/local/sbin/named'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x080ae7cd in ?? ()
> (gdb) trace
> trace command requires an argument
> (gdb) trace 0
> No symbol table is loaded.  Use the "file" command.
> 
> Any other folks have similar issue? Or any suggestions? The reason we run lat
> est is because 9.3.4 will hog cpu and we have to restart named to remediate t
> he slow resolve.
> 
> Thanks.
> 
> shiling
> 
> 
> 
> 
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org