In message <dc9f15e5-089e-4356-ae88-0750cbab7...@newgeo.com>, Scott Haneda writ
es:
> On May 7, 2009, at 6:51 PM, Mark Andrews wrote:
>
> > In message <8b717588-3e36-4596-9b11-de03e1ca4...@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?
> >>
> >> r...@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_andr...@isc.org
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
