Core dumping DLZ

[Adam Tkac]

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.