[ale] How to debug a program that just goes away

[JK]

Chris's strace idea will at least let you see what it was
doing (last system call) when it died.

Also, check whether there are any core files for it.
There are some user-level accounting parameters that
affect when/how core dumps are generated, but I can't
remember what they are at the moment. "man -k core"
might be your friend there. Anyway, if you have
a core file, you can load it up in gdb (or your fave
debugger) and see exactly WTF it was doing at the
moment the Grim Reaper came calling.

Also, you can set handlers for SIGKILL, SIGILL, etc that
do something informative when called, so you can see if
any of those are causing the problem. (Though sighandlers
are not supposed to call any other functions, so you may
need to be kinda clever to make this useful. Combined
with a corefile, though, you might get some helpful
behavior -- eg make each signal handler set some static
int to a unique value when called, and check that
value in gdb post-mortem.)

If your program is a memory hog, the Out-Of-Memory
killer in the kernel's VM subsystem may be the culprit.

-- JK


On 2/26/2010 7:13 AM, Jim Lynch wrote:
> Chris Fowler wrote:
>> Have you used strace to see if it is blocking in a system call?
>>
>>
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>>
>>
> Would that cause it to just go away?  It's not that the program stops
> processing, it's that it disappears from the process table. It's as if a
> kill -9 was sent to it.
>
> Thanks,
> Jim.
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>


-- 
We Americans are a freedom-loving people, and nothing says "freedom"
like Getting Away With It. -- Guy Forsyth, "Long Long Time"