- Pharo-dev - lists.pharo.org

Re: [Pharo-project] How to resurrect an unrepsonsive image?

by Norbert Hartl

Am 08.12.2011 um 19:08 schrieb Eliot Miranda: > Hi Norbert, > > On Thu, Dec 8, 2011 at 2:04 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > Eliot, > > can you take a look at the attached crash.dmp file? My knowledge about the internals is limited so I'm not a good candidate to get a feeling what could have been gone wrong. > If I would have to guess I would think there is a dead lock in ExternalSemaphoreTable. It looks to me as if the outgoing network connect tries to register an external object at the same time the snapshot:andQuit: tries to clear the external objects. But I know nothing how this works. > > OK, as a favour to you. Next time you do the leg work. But all the info you need is in the dump. First thing, the active process is the idle process: > > Process 0x8f1d2a8 priority 10 > 0xbff60000 M ProcessorScheduler class>idleProcess 64373036: a(n) ProcessorScheduler class > 0x8f929b0 s [] in ProcessorScheduler class>startUp > 0x8f1d248 s [] in BlockClosure>newProcess > > (you can see form the C stack trace that the VM is looping doing primitiveRelinquishProcessor) > > The next process is the finalization process, which has nothing to do. > > Then Process 0x8d73268 priority 20 is trying to do a connect but is blocks in a critical section trying to register one or other of the Socket's semaphores. > > Then Process 0x8f23b98 priority 20 is trying to do a snapshot and is blocked in a critical section doing SmalltalkImage>clearExternalObjects. > Eliot, thanks for looking into this. As you can see from my guessing I did read the stack traces. And it seems I saw the same like you did :) > So my guesses are either that > a) something terminated a process that was in the critical section for registering external objects and the semaphore protecting it is missing a signal, or > b) there is a bug in the code and that if a process is in the critical section registering an external object then SmalltalkImage>clearExternalObjects my lock-up. > this is the reason I was asking. I'm just not too fond of most of the code involved and I expected you are. These guesses of you exceed my capability of guessing to some extent and it is very helpful. > But you can read Smalltalk stack traces as well as I. Just look at them. There are only 11 of them. I was fishing for some extra bits of information. And I'm glad I'm not too shy to ask stupid questions or do some random nagging. Sorry for bothering you with this. Norbert > > > Norbert > > > > Am 07.12.2011 um 22:49 schrieb Eliot Miranda: > >> >> >> On Wed, Dec 7, 2011 at 10:55 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> That assumes there is an error. Another (even more frustrating) failure arises when an image does nothing. It is very help to be able to get callstacks in that scenario. >> >> On Mac and Linux the Cog VM responds to SIGUSR1 by dumping all stacks to crash.dmp. >> >> >> >> >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Javier PimÃ¡s [elpochodelagente(a)gmail.com] >> Sent: Wednesday, December 07, 2011 1:52 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] How to resurrect an unrepsonsive image? >> >> Probably you have a crash.dmp or a PharoDebug.log which tells you what is happening. Look at the backtrace to see what causes the error and then maybe there's some way to help you fixing it. >> >> Cheers, >> Javier. >> >> On Wed, Dec 7, 2011 at 10:47 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >> I have a headless image that was running for a couple of days. Now it is not responding anymore. The image was running still but the sockets for http and vnc were closed and restarting the image just brings it up without any sockets opened. >> Injecting something via script does not work either. I copied the image to my desktop and tried a few things but no success. >> What would be a good way to get a glimpse of what is causing problems? >> I had Scheduler running that saved the image every hour. And the image itself issues http request to the outside world every 10 minutes. >> >> thanks, >> >> Norbert >> >> >> >> -- >> Lic. Javier PimÃ¡s >> Ciudad de Buenos Aires >> >> >> >> -- >> best, >> Eliot

Dec. 8, 2011

Re: [Pharo-project] How to resurrect an unrepsonsive image?

by Eliot Miranda

Hi Norbert, On Thu, Dec 8, 2011 at 2:04 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > Eliot, > > can you take a look at the attached crash.dmp file? My knowledge about the > internals is limited so I'm not a good candidate to get a feeling what > could have been gone wrong. > If I would have to guess I would think there is a dead lock in > ExternalSemaphoreTable. It looks to me as if the outgoing network connect > tries to register an external object at the same time the snapshot:andQuit: > tries to clear the external objects. But I know nothing how this works. > OK, as a favour to you. Next time you do the leg work. But all the info you need is in the dump. First thing, the active process is the idle process: Process 0x8f1d2a8 priority 10 0xbff60000 M ProcessorScheduler class>idleProcess 64373036: a(n) ProcessorScheduler class 0x8f929b0 s [] in ProcessorScheduler class>startUp 0x8f1d248 s [] in BlockClosure>newProcess (you can see form the C stack trace that the VM is looping doing primitiveRelinquishProcessor) The next process is the finalization process, which has nothing to do. Then Process 0x8d73268 priority 20 is trying to do a connect but is blocks in a critical section trying to register one or other of the Socket's semaphores. Then Process 0x8f23b98 priority 20 is trying to do a snapshot and is blocked in a critical section doing SmalltalkImage>clearExternalObjects. So my guesses are either that a) something terminated a process that was in the critical section for registering external objects and the semaphore protecting it is missing a signal, or b) there is a bug in the code and that if a process is in the critical section registering an external object then SmalltalkImage>clearExternalObjects my lock-up. But you can read Smalltalk stack traces as well as I. Just look at them. There are only 11 of them. HTH Eliot > Norbert > > > > Am 07.12.2011 um 22:49 schrieb Eliot Miranda: > > > > On Wed, Dec 7, 2011 at 10:55 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > >> That assumes there is an error. Another (even more frustrating) >> failure arises when an image does nothing. It is very help to be able to >> get callstacks in that scenario. >> > > On Mac and Linux the Cog VM responds to SIGUSR1 by dumping all stacks to > crash.dmp. > > >> >> >> >> >> ------------------------------ >> *From:* pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Javier PimÃ¡s [ >> elpochodelagente(a)gmail.com] >> *Sent:* Wednesday, December 07, 2011 1:52 PM >> *To:* Pharo-project(a)lists.gforge.inria.fr >> *Subject:* Re: [Pharo-project] How to resurrect an unrepsonsive image? >> >> Probably you have a crash.dmp or a PharoDebug.log which tells you what >> is happening. Look at the backtrace to see what causes the error and then >> maybe there's some way to help you fixing it. >> >> Cheers, >> Javier. >> >> On Wed, Dec 7, 2011 at 10:47 AM, Norbert Hartl <norbert(a)hartl.name>wrote: >> >>> I have a headless image that was running for a couple of days. Now it is >>> not responding anymore. The image was running still but the sockets for >>> http and vnc were closed and restarting the image just brings it up without >>> any sockets opened. >>> Injecting something via script does not work either. I copied the image >>> to my desktop and tried a few things but no success. >>> What would be a good way to get a glimpse of what is causing problems? >>> I had Scheduler running that saved the image every hour. And the image >>> itself issues http request to the outside world every 10 minutes. >>> >>> thanks, >>> >>> Norbert >>> >> >> >> >> -- >> Lic. Javier PimÃ¡s >> Ciudad de Buenos Aires >> > > > > -- > best, > Eliot > >

Dec. 8, 2011

Re: [Pharo-project] The tools are dreadfully slow in 1.4

by Sean P. DeNigris

Igor Stasenko wrote > > details, where the details... > SystemBrowser default newOnClass: UITheme class selector: #exampleBasicControls. "Jeopardy theme playing for ~10 seconds" -- View this message in context: http://forum.world.st/The-tools-are-dreadfully-slow-in-1-4-tp4173491p417365… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 8, 2011

Re: [Pharo-project] A possible bug in GZip streams

by Sven Van Caekenberghe

On 08 Dec 2011, at 18:43, Martin Dias wrote: > I think the problem is that this method supposes n >= 1: Yeah, that is why I propose a guard, maybe in this method n = 0 ifTrue: [ ^ buffer] but I have no time to analyze the consequences/implications. Sven

Dec. 8, 2011

Re: [Pharo-project] A possible bug in GZip streams

by Martin Dias

Hi! > I guess you could add a guard for the #nextInto: message send in > GZipReadStream>>#nextString when the length is 0. But I haven't tried. > > Sven > > I think the problem is that this method supposes n >= 1: InflateStream>> next: n into: buffer startingAt: startIndex "Read n objects into the given collection. Return aCollection or a partial copy if less than n elements have been read." | c numRead count | numRead := 0. ["Force decompression if necessary" (c := self next) == nil ifTrue:[^buffer copyFrom: 1 to: startIndex+numRead-1]. "Store the first value which provoked decompression" buffer at: startIndex + numRead put: c. numRead := numRead + 1. "After collection has been filled copy as many objects as possible" count := (readLimit - position) min: (n - numRead). buffer replaceFrom: startIndex + numRead to: startIndex + numRead + count - 1 with: collection startingAt: position+1. position := position + count. numRead := numRead + count. numRead = n] whileFalse. ^buffer Martin

Dec. 8, 2011

Re: [Pharo-project] The tools are dreadfully slow in 1.4

by Igor Stasenko

On 8 December 2011 18:14, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > It feels worse than pre-cog ;-) > details, where the details... > -- > View this message in context: http://forum.world.st/The-tools-are-dreadfully-slow-in-1-4-tp4173491p417349… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

Dec. 8, 2011

[Pharo-project] The tools are dreadfully slow in 1.4

by Sean P. DeNigris

It feels worse than pre-cog ;-) -- View this message in context: http://forum.world.st/The-tools-are-dreadfully-slow-in-1-4-tp4173491p417349… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 8, 2011

Re: [Pharo-project] A possible bug in GZip streams

by Levente Uzonyi

On Thu, 8 Dec 2011, Mariano Martinez Peck wrote: > no one? :( This case has at least 3 different bugs (in Squeak). One of them is a heisenbug. :) Levente > > On Tue, Dec 6, 2011 at 7:32 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > >> I forgot to say that I am working on a recent Pharo 1.3. >> >> And it is not only GZipWriteStream but also ZipWriteStream >> and ZLibWriteStream . >> >> MartÃn >> >> On Mon, Dec 5, 2011 at 10:47 AM, Martin Dias <tinchodias(a)gmail.com> wrote: >> >>> Hi, >>> >>> I get a SubscriptOutOfBounds error when I evaluate: >>> >>> | aStream zipStream | >>> >>> aStream := ByteArray new writeStream binary. >>> zipStream := GZipWriteStream on: aStream. >>> zipStream nextStringPut: ''. >>> zipStream nextStringPut: ''. >>> zipStream close. >>> aStream close. >>> aStream := aStream contents readStream binary. >>> zipStream := GZipReadStream on: aStream. >>> zipStream nextString. >>> zipStream nextString. >>> zipStream close. >>> aStream close. >>> >>> The error doesn't happen when I put just one string (instead of two). >>> >>> Do you see something wrong in the code? Should I report a bug? >>> >>> Thanks, >>> MartÃn >>> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 8, 2011

Re: [Pharo-project] A possible bug in GZip streams

by Mariano Martinez Peck

On Thu, Dec 8, 2011 at 5:09 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > It is certainly a bug ;-) > > Strangely, non-empty strings work: > > Yes, in fact, we found that gzip was not working in some "random" cases and Martin could come to the gulty! > | aStream zipStream | > > aStream := ByteArray new writeStream binary. > zipStream := GZipWriteStream on: aStream. > zipStream nextStringPut: '123'. > zipStream nextStringPut: 'ABC'. > zipStream close. > aStream close. > > aStream := aStream contents readStream binary. > zipStream := GZipReadStream on: aStream. > zipStream nextString. > zipStream nextString. > zipStream close. > aStream close. > > I guess you could add a guard for the #nextInto: message send in > GZipReadStream>>#nextString when the length is 0. But I haven't tried. > > Ok, we will try. Thanks, we wanted to know whether we were doing something wrong or not. Don't you use this stream for Zinc as well ? > Sven > > On 08 Dec 2011, at 16:53, Mariano Martinez Peck wrote: > > > no one? :( > > > > On Tue, Dec 6, 2011 at 7:32 AM, Martin Dias <tinchodias(a)gmail.com> > wrote: > > I forgot to say that I am working on a recent Pharo 1.3. > > > > And it is not only GZipWriteStream but also ZipWriteStream and > ZLibWriteStream . > > > > MartÃn > > > > On Mon, Dec 5, 2011 at 10:47 AM, Martin Dias <tinchodias(a)gmail.com> > wrote: > > Hi, > > > > I get a SubscriptOutOfBounds error when I evaluate: > > > > | aStream zipStream | > > > > aStream := ByteArray new writeStream binary. > > zipStream := GZipWriteStream on: aStream. > > zipStream nextStringPut: ''. > > zipStream nextStringPut: ''. > > zipStream close. > > aStream close. > > > > aStream := aStream contents readStream binary. > > zipStream := GZipReadStream on: aStream. > > zipStream nextString. > > zipStream nextString. > > zipStream close. > > aStream close. > > > > The error doesn't happen when I put just one string (instead of two). > > > > Do you see something wrong in the code? Should I report a bug? > > > > Thanks, > > MartÃn > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 8, 2011

Re: [Pharo-project] A possible bug in GZip streams

by Sven Van Caekenberghe

It is certainly a bug ;-) Strangely, non-empty strings work: | aStream zipStream | aStream := ByteArray new writeStream binary. zipStream := GZipWriteStream on: aStream. zipStream nextStringPut: '123'. zipStream nextStringPut: 'ABC'. zipStream close. aStream close. aStream := aStream contents readStream binary. zipStream := GZipReadStream on: aStream. zipStream nextString. zipStream nextString. zipStream close. aStream close. I guess you could add a guard for the #nextInto: message send in GZipReadStream>>#nextString when the length is 0. But I haven't tried. Sven On 08 Dec 2011, at 16:53, Mariano Martinez Peck wrote: > no one? :( > > On Tue, Dec 6, 2011 at 7:32 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > I forgot to say that I am working on a recent Pharo 1.3. > > And it is not only GZipWriteStream but also ZipWriteStream and ZLibWriteStream . > > MartÃn > > On Mon, Dec 5, 2011 at 10:47 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi, > > I get a SubscriptOutOfBounds error when I evaluate: > > | aStream zipStream | > > aStream := ByteArray new writeStream binary. > zipStream := GZipWriteStream on: aStream. > zipStream nextStringPut: ''. > zipStream nextStringPut: ''. > zipStream close. > aStream close. > > aStream := aStream contents readStream binary. > zipStream := GZipReadStream on: aStream. > zipStream nextString. > zipStream nextString. > zipStream close. > aStream close. > > The error doesn't happen when I put just one string (instead of two). > > Do you see something wrong in the code? Should I report a bug? > > Thanks, > MartÃn > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 8, 2011