On 12/9/2009 2:09 AM, Joseph S wrote:
> I was able to get a backtrace by running in gdb.
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x43007940 (LWP 30215)]
> 0x000000367ae796d0 in strlen () from /lib64/libc.so.6
> (gdb) bt
> #0  0x000000367ae796d0 in strlen () from /lib64/libc.so.6
> #1  0x000000367ae46b69 in vfprintf () from /lib64/libc.so.6
> #2  0x000000367ae6988a in vsnprintf () from /lib64/libc.so.6
> #3  0x0000000000417618 in slon_log (level=<value optimized out>, 
> fmt=0x41edd8 " ssy_action_list value: %s\n") at misc.c:175
> #4  0x00000000004093d0 in sync_event (node=0x1006d3b0, local_conn=<value 
> optimized out>, wd=0x1006cbd0, event=0x1009bfa0) at remote_worker.c:4353
> #5  0x000000000040ba42 in remoteWorkerThread_main (cdata=<value 
> optimized out>) at remote_worker.c:630
> #6  0x000000367ba064a7 in start_thread () from /lib64/libpthread.so.0
> #7  0x000000367aed3c2d in clone () from /lib64/libc.so.6

What puzzles me is that the code in remote_worker.c just one line before 
the slon_log() call did (apparently successful) do a strlen() on exactly 
that ssy_action_list. So why on earth does the same inside of vfprintf() 
fail?


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin