Core dumping DLZ

[Scott Haneda]

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@ *