On Thu, May 07, 2009 at 09:20:28PM -0700, Scott Haneda wrote: > 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.
Please open a ticket in Red Hat issue tracker (preferred method) or in Red Hat bugzilla about this issue. It is a bug somewhere in code. Regards, Adam -- Adam Tkac, Red Hat, Inc. _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
