[Bug-openmcl] Debugging crashes of dppccl

[Erik Pearson]

I tried invoking with the --no-sigtrap option, but it still hangs when gdb 
connects to it, and resumes when gdb exits.

Erik.

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

> 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."
> _______________________________________________
> 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."