[Bug-openmcl] Debugging crashes of dppccl

[Erik Pearson]

Is there a procedure for compiling dppccl so that it will produce useful 
information upon crashing? I'm testing an app that runs continuously (i.e. 
a server), waking up a process every few minutes to run a set of registered 
functions. It is doing website monitoring, so each function goes out, 
fetches a web page, looks at it, and saves the results. The server then 
will write to a file or send an email alert.

After this process repeats about 250-300 times (at an interval of 15 
seconds for testing...) dppccl will just up and die, printing no messages, 
and returning to the shell, and leaving behind no core file. Well, that is 
not quite true. The last time this happened the message "Abort trap" was 
printed.

This is running under the bleeding edge, checked out a couple of days ago 
with a few manual tweaks to the threading code.

This just go away if it is just Gary fiddling with something. But in case 
not, or in any case, I'm wondering how to get diagnostic information on the 
cause of such crashes. I've looked _very_ briefly at gdb, and had it set up 
to monitor the dppccl process, but it caused dppccl to hang after a few 
minutes -- dppccl continued just fine after gdb was exited.

I'm also going to be looking at different methods of exercising the code 
and isolating the problem, but this is made difficult since it happens 
after many iterations, and the code that is being run is pretty "wild" in 
that it interacts with the network layer in multiple ways involving threads 
and timeouts. (e.g. I've run the code also with > 700 iterations when 
monitoring a simple, close website which has never timed out and which is 
on the local subnet.)

Thanks,

Erik.

--
Erik Pearson
Adaptations
"Adaptation: It's not just for finches anymore."