In article <3D9D1811.nail1Z311GE@andromeda.rutgers.edu>, William Yodlowsky <wyodlows@andromeda.rutgers.edu> wrote; } Program received signal SIGSEGV, Segmentation fault. } 0xff141f74 in realfree () from /usr/lib/libc.so.1 } (gdb) bt } #0 0xff141f74 in realfree () from /usr/lib/libc.so.1 } #1 0xff142880 in cleanfree () from /usr/lib/libc.so.1 } #2 0xff1419b4 in _malloc_unlocked () from /usr/lib/libc.so.1 } #3 0xff1418a8 in malloc () from /usr/lib/libc.so.1 } #4 0x2abf8 in xalloc () } #5 0x2adc0 in ol_space_alloc () As I wrote before mine was also dead at malloc(). I just tried ugly patching not to zero sized allocation, which means allocated size will be more than one byte if xalloc() tries to allocate 0 like this; if (size == 0) size++; Even with the patch, I still get the core; (gdb) bt #0 0xff141bec in realfree () from /usr/lib/libc.so.1 #1 0xff1424f8 in cleanfree () from /usr/lib/libc.so.1 #2 0xff14162c in _malloc_unlocked () from /usr/lib/libc.so.1 #3 0xff141520 in malloc () from /usr/lib/libc.so.1 #4 0x21cc0 in xalloc () #5 0x17840 in make_log_info (length=0, msg=0x0, prefix=0x0, flags=0) at log.c:272 #6 0x15ba4 in do_handle_line (self=0x55b68, length=164, data=0x56490 "<150>Oct 4 17:29:47 local@ks0003 named[13188]: [ID 866145 local2.info] Oct 04 17:29:47.956security: client 10.17.0.25#58886: query 'ks0302.XXX.ne.jp/IN' denied\n<150>Oct 4 17:29:50 local@ks0003 n"..., addr=0x56490, addrlen=0) at sources.c:68 #7 0x15d48 in do_read_line (h=0x56534, read=0xffbef998) at sources.c:138 #8 0x1ff54 in read_callback () #9 0x1fbcc in io_iter () #10 0x152d8 in main_loop (backend=0x39758) at main.c:192 #11 0x159c8 in main (argc=0, argv=0xffbefd04) at main.c:516 (gdb) frame 5 #5 0x17840 in make_log_info (length=0, msg=0x0, prefix=0x0, flags=0) at log.c:272 272 NEW_SPACE(self); from above trace and my experience at other development project, I think this is due to the memory handling problem by the program bug. -- Katsuhiro Kondou