Core dumping DLZ

[Mark Andrews]

In message <DC9F15E5-089E-4356-AE88-0750CBAB7308 at newgeo.com>, Scott Haneda writ
es:
> On May 7, 2009, at 6:51 PM, Mark Andrews wrote:
> 
> > In message <8B717588-3E36-4596-9B11-DE03E1CA4F03 at newgeo.com>, Scott  
> > Haneda writ
> > es:
> >> On May 7, 2009, at 6:08 PM, Scott Haneda wrote:
> >>
> >>> What can a core dump tell me to help trace this issue down and solve
> >>> it?  Named is going deaf/dead for some reason, perhaps related, I  
> >>> need
> >>> it to keep up.
> >>
> >> I did a little searching and found how to look into the core dumps,
> >> here is what is happening.  How can I solve this?
> >>
> >> root at host [core_dumps:] $ gdb /usr/sbin/named-sdb core.9810
> >> GNU gdb Fedora (6.8-27.el5)
> >> Copyright (C) 2008 Free Software Foundation, Inc.
> >> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.ht
> ml
> >>
> >>
> >> [snip.. loading symbols]
> >>
> >> Loaded symbols for /lib64/libsepol.so.1
> >> Reading symbols from /lib64/libnss_files.so.2...done.
> >> Loaded symbols for /lib64/libnss_files.so.2
> >> Core was generated by `/usr/sbin/named-sdb -u named'.
> >> Program terminated with signal 6, Aborted.
> >> [New process 9810]
> >> #0  0x00002adb2b0e0215 in raise () from /lib64/libc.so.6
> >> (gdb) backtrace
> >> #0  0x00002adb2b0e0215 in raise () from /lib64/libc.so.6
> >> #1  0x00002adb2b0e1cc0 in abort () from /lib64/libc.so.6
> >> #2  0x00002adb27c4c9e0 in assertion_failed (file=0x2adb2922428b
> >> "mem.c", line=918, type=<value optimized out>, cond=0x2adb292245b5
> >> "ctx->stats[i].gets == 0U")
> >>     at ./main.c:166
> >> #3  0x00002adb29202488 in destroy (ctx=0x2adb27ece6c0) at mem.c:918
> >> #4  0x00002adb29202755 in isc_mem_destroy (ctxp=0x2adb27ea0340) at
> >> mem.c:1067
> >> #5  0x00002adb27c4dc78 in main (argc=0, argv=0x7fff82e7e928) at ./
> >> main.c:1064
> >
> > 	This is indicative of a memory / reference leak being
> > 	detected on shutdown.
> 
> Hi Mark, thanks.  No one ever shuts down the server/process/app, so  
> something else must be causing that.  Would that mean this particular  
> core dump is a result of some other crash causing it to shut down?

	I beg to differ.  Named only gets to this position in the
	code if it has been told to shut itself down.  Note this
	may happen as a side effect of shutting the machine itself
	down.
 
> Is this http://people.redhat.com/atkac/bind/ the only place I can get  
> a srpm for dlz/sdb?  Sorry, I am not familiar with rpm or red hat, and  
> just need to do my best to resolve this, or find a consultant who can  
> help me resolve this.
> 
> I will go explore the other core dumps and see if they tell anything  
> more interesting.  Thanks for your help.
> -- 
> Scott * If you contact me off list replace talklists@ with scott@ *
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org