[Bug-openmcl] Debugging crashes of dppccl

[Erik Pearson]

Hmm, one possible clue. I just halted a test after 1800 iterations (without 
problems) -- and found that the initial process (0) was no longer in 
existence. That must be bad. I had noticed the disappearance of process 0 
several times in the past couple of weeks of testing, but had saved it for 
a rainy day. It necessitates killing the process from the shell.

Erik.

--On Thursday, March 4, 2004 3:21 PM -0800 Erik Pearson 
<erik at adaptations.com> wrote:

> 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."
> _______________________________________________
> Bug-openmcl mailing list
> Bug-openmcl at clozure.com
> http://clozure.com/mailman/listinfo/bug-openmcl



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