December 2011 - Pharo-dev - lists.pharo.org

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

by Marcus Denker

On Dec 8, 2011, at 9:04 PM, Schwab,Wilhelm K wrote: > Even in Dolphin's earliest docs Sometimes I wonder if you are able (physically) to write a mail that does not contain the word "Dolphin" (sorry...) Marcus -- Marcus Denker -- http://marcusdenker.de

Dec. 8, 2011

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

by Sven Van Caekenberghe

On 08 Dec 2011, at 20:38, Martin Dias wrote: > thanks, it fixes the issue (inserted at the beginning of InflateStream>>next:into:startingAt:). Great! > The same issue should happen sending InflateStream>>readInto:startingAt:count: Yes, most probably. > I guess we should add some tests in CompressionTests package. I can do it on a couple of days. Yes, that would be super. Thanks, Martin. Sven

Dec. 8, 2011

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

by Martin Dias

On Thu, Dec 8, 2011 at 2:50 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > 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] > thanks, it fixes the issue (inserted at the beginning of InflateStream>> next:into:startingAt:). The same issue should happen sending InflateStream>>readInto:startingAt:count: I guess we should add some tests in CompressionTests package. I can do it on a couple of days. > but I have no time to analyze the consequences/implications. > > Sven > > > >

Dec. 8, 2011

[Pharo-project] Smalltalk Industry Conference deadlines reminder

by Alan Knight

The Smalltalk Industry Conference 2012 is coming up March 19-21, and submission deadlines are coming up sooner. This year there are two parts to the conference, so there could be some confusion. -*Smalltalk Industry Conference*: This is the traditional Smalltalk Solutions program. To submit, you just need summary information for the talk. The presentations are, at least sometimes, recorded, but there aren't published papers. The deadline for those submissions is VERY SOON -_December 15th_. Call for participation ishere <http://www.stic.st/2011/10/smalltalk-solutions-is-now-called-smalltalk-indu…>. -*Smalltalk Directions*: This is the academic part of the conference, new this year. It accepts academic papers, which will be refereed and a selection of which will be submitted to the Journal of Object Technology. The deadline for those submissions is_January 6th, 2012_. The call for participation ishere <http://www.stic.st/2011/11/smalltalk-directions-call-for-participation/>.

Dec. 8, 2011

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

by Schwab,Wilhelm K

Eliot, It would be nice to have the #name of each process in the dump. I often end up with many similar/identical processes, and the name is very useful in sorting out which among them has/have strayed. Re guess (a - unsignaled semaphore), does that perhaps suggest a missing #ensure: block? Another possibility (just asking) is that we are using a semaphore for mutual exclusion when a mutex would be a better choice?? When I started using threads, I had a robust mutex class "from the start" and the differences between a mutual exclusion semaphore and a mutex were striking. Re guess (b - lockup in #clearExternalObjects), Norbert mentioned saving the image in connection with this. Saving the image is a very "main thread" activity, and as such, there might be a need to queue a deferred action vs. invoking the code from a background thread. I was going to add something about my reservations on our weak collections, which (IMHO must be thread safe and self-cleaning, and are not in Sqeak/Pharo). Even in Dolphin's earliest docs, weak collections and finalization were one topic, for good reason. Toward that end, I looked at ExternalSemaphoreTable, expecting to find it subclassed or using a weak collection of some type. What I found is a #forMutualExclusion semaphore in a a situation where I would use a Mutex. This looks like a matter of evolution and timing. Squeak dates back to an era before structured exception handling and improvements like Mutex. Dolphin got started after Squeak, with either a two or fifteen year head start, depending on how one wants to call it. Dolphin was built from the ground up to have weak collections, finalization, and full set of process synchronization tools, making Mutex a part of the toolkit when its sockets were written. We have Mutex now, and probably should be using it more widely than we do. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Thursday, December 08, 2011 1:08 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] How to resurrect an unrepsonsive image? Hi Norbert, On Thu, Dec 8, 2011 at 2:04 AM, Norbert Hartl <norbert(a)hartl.name<mailto:norbert@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<mailto:bschwab@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<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Javier PimÃ¡s [elpochodelagente(a)gmail.com<mailto:elpochodelagente@gmail.com>] Sent: Wednesday, December 07, 2011 1:52 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:norbert@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 Marcus Denker

On Dec 8, 2011, at 7:07 PM, Sean P. DeNigris wrote: > > Igor Stasenko wrote >> >> details, where the details... >> > > SystemBrowser default newOnClass: UITheme class selector: > #exampleBasicControls. > "Jeopardy theme playing for ~10 seconds" > Hmm... I can not see any performance problems when I do that. -- Marcus Denker -- http://marcusdenker.de

Dec. 8, 2011

Re: [Pharo-project] Debugger Not Feeling Well

by Marcus Denker

On Dec 8, 2011, at 4:01 PM, Sean P. DeNigris wrote: > > Sean P. DeNigris wrote >> >> It's working again > > Um, I meant feeling better, but not exactly working ;-) The contextual info > is not lined up with the selected code as you step through. For example, > while stepping through the following: > > | candidates | > candidates := self eligibleClasses select: [ :e | e category beginsWith: > package ]. > ^ candidates atRandom. > > When "atRandom" is selected, the block is displayed for "stack top". It's > only when I press "Over" again that the candidates collection is "stack > top", but by that point, the return is selected. I have to press "Over" > three more times to return to the calling method. I'm also getting an > intermittent "SubscriptOutOfBounds" error while working with the debugger, > which sounds very familiar... > can you try to revert the change in #runUntilErrorOrReturnFrom: (file in the attached change): -- Marcus Denker -- http://marcusdenker.de

Dec. 8, 2011

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