Smalltalk › Pharo › Pharo Smalltalk Users

Interpreting a crash.dmp file was: Re: [Seaside] Seaside image health check

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

Paul DeBruicker

Interpreting a crash.dmp file was: Re: [Seaside] Seaside image health check

On 11-12-22 08:46 AM, Levente Uzonyi wrote:
> If you're using CogVM, then you can force printing the content of all
> smalltalk stacks to stdout by sending a USR1 signal to the process with
> the following command:
>
> kill -USR1 <pid>
>
> The currently active process will be printed first.

Thanks Levente.

I have an image that stops responding to seaside requests and maxes out
the CPU. This happens after a random amount of time generally longer
than a day. Sometimes I can get it to pop out of the hang by signing in
through the RFB server, but sometimes not.

In this Pharo-1.3-13315 image (Ubuntu 64bit, Cog 2522 from Eliot's site)
I'm using RFB and have applied the fixes described here:
https://code.google.com/p/pharo/issues/detail?id=4829#c6

I think that the crash.dmp file shows that the image was stuck trying to
create an IdentitySet from an array. Maybe I need to take a sample of
the "kill -USR1 <pid>" commands to know for sure.

The other thing that's weird is that in the crash.dmp file I don't see
the Seaside server process. I'm using Comanche as the server adapter.

Is there anything I should look for in my application or image to get
more info about the disruption in processing requests?

Thanks

Paul

crash.dmp (13K) Download Attachment

Stéphane Ducasse

Re: Interpreting a crash.dmp file was: Re: [Seaside] Seaside image health check

Hi Paul

keep us informed because we really want to have a solid infrastructure. We are sorry for this problem.

Stef

> On 11-12-22 08:46 AM, Levente Uzonyi wrote:
>> If you're using CogVM, then you can force printing the content of all
>> smalltalk stacks to stdout by sending a USR1 signal to the process with
>> the following command:
>>
>> kill -USR1 <pid>
>>
>> The currently active process will be printed first.
>
> Thanks Levente.
>
>
> I have an image that stops responding to seaside requests and maxes out the CPU. This happens after a random amount of time generally longer than a day. Sometimes I can get it to pop out of the hang by signing in through the RFB server, but sometimes not.
>
> In this Pharo-1.3-13315 image (Ubuntu 64bit, Cog 2522 from Eliot's site) I'm using RFB and have applied the fixes described here:
> https://code.google.com/p/pharo/issues/detail?id=4829#c6
>
> I think that the crash.dmp file shows that the image was stuck trying to create an IdentitySet from an array. Maybe I need to take a sample of the "kill -USR1 <pid>" commands to know for sure.
>
> The other thing that's weird is that in the crash.dmp file I don't see the Seaside server process. I'm using Comanche as the server adapter.
>
>
> Is there anything I should look for in my application or image to get more info about the disruption in processing requests?
>
> Thanks
>
> Paul
> <crash.dmp>