On May 7, 2009, at 6:51 PM, Mark Andrews wrote:
(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.
I just had two more happen. This is not even a production server as
of yet, it is being readied for that though. There should be very
little hitting named-sdb at this point...
(gdb) backtrace
#0 0x00002af5a089fdfb in ?? () from /usr/lib64/mysql/
libmysqlclient.so.15
#1 0x00002af5a08a0179 in my_net_read () from /usr/lib64/mysql/
libmysqlclient.so.15
#2 0x00002af5a0899922 in cli_safe_read () from /usr/lib64/mysql/
libmysqlclient.so.15
#3 0x00002af5a089a9f9 in ?? () from /usr/lib64/mysql/
libmysqlclient.so.15
#4 0x00002af5a0898f9e in mysql_real_query ()
from /usr/lib64/mysql/libmysqlclient.so.15
#5 0x00002af59f09c67a in mysql_get_resultset (zone=0x4542f960
"ns1.*****.com",
record=<value optimized out>, client=0x0, query=4,
dbdata=0x2af59f3391e0,
rs=0x4542f918) at ../../contrib/dlz/drivers/dlz_mysql_driver.c:324
#6 0x00002af59f09c80b in mysql_findzone (driverarg=<value optimized
out>,
dbdata=0x2af59f3391e0, name=0x4542f960 "ns1.******.com")
at ../../contrib/dlz/drivers/dlz_mysql_driver.c:515
#7 0x00002af59f7c8353 in dns_sdlzfindzone (driverarg=0x2af59f2fc410,
dbdata=0x2af59f3391e0, mctx=0x2af59f2ea6c0, rdclass=1,
name=0x4542fdf0,
dbp=0x45430058) at sdlz.c:1461
#8 0x00002af59f72cf22 in dns_dlzfindzone (view=0x2af59f3d8d20,
name=0x2aaaaafda090,
minlabels=3, dbp=0x45430058) at dlz.c:294
#9 0x00002af59f06add4 in query_getdb (client=0x2aaaaafd1b20,
name=0x2aaaaafda090,
qtype=<value optimized out>, options=0, zonep=0x45431050,
dbp=0x454310b8,
versionp=0x45431058, is_zonep=0x454310cc) at query.c:925
#10 0x00002af59f06fe92 in query_find (client=0x2aaaaafd1b20,
event=0x0, qtype=1)
at query.c:3805
#11 0x00002af59f0735cd in ns_query_start (client=0x2aaaaafd1b20) at
query.c:5095
#12 0x00002af59f06026d in client_request (task=<value optimized out>,
event=<value optimized out>) at client.c:1898
#13 0x00002af5a0629e2c in run (uap=<value optimized out>) at task.c:862
#14 0x00002af5a1ae2367 in start_thread () from /lib64/libpthread.so.0
#15 0x00002af5a259f0ad in clone () from /lib64/libc.so.6
This looks MySql related. I have mysql query logging enabled, so I
can see what comes in. So far, nothing looks malformed, which is a
sure fire way to make one of these core dumps happen.
--
Scott * If you contact me off list replace talklists@ with scott@ *
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
