12186 image quit problem
Locked
123
123
 
|
also, it 'hangs' because
InputEventSensor>>shutdown runs before MCMethodDefinition>>shutdown So, you can't interrupt it with alt-. , because nobody handles it anymore. On 8 October 2010 18:06, Igor Stasenko <[hidden email]> wrote: > 2010/10/8 Pavel Krivanek <[hidden email]>: >> Hi Marcus, >> is that really all what happened between 12172 and 12186? >> >> update12186 >> Issue 3071: fixing timestamp tests >> Issue 3068: Non portable SmalltalkImage>>platformName deprecationWarning >> Issue 3063: removing explain >> Issue 3039: There should not be any configuration on Core >> It doesn't explain the problems with VM versions and in 12186 I cannot build >> the PharoKernel (it hangs without error in unload phase) >> -- Pavel >> > please , tell me if it keep hanging after you doing: > > WeakArray restartFinalizationProcess. > > it seems like a deadlock with WeakArray's FinalizationLock or > FinalizationSemaphore. > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: 12186 image quit problem
|
|
In reply to this post by Igor Stasenko
On Fri, 8 Oct 2010, Igor Stasenko wrote:
> 2010/10/8 Alexander Lazarević <[hidden email]>: > This is reproducible for me if I do: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfExternalWebBrowser'; > load. > > (Smalltalk at: #ConfigurationOfExternalWebBrowser) load > > Find the error log attached. FFI-Pools.em.2 does not exists. But i picked ar.1 version and continued, that save&quit everything works well It should be FFI-Pools.eem.2. Levente > > Alex > > 2010/10/8 Alexander Lazarević <[hidden email]>: >> Just when I was about to test drive Torstens configuration of >> ExternalWebBrowser, the image hangs somewhere while loading. I'm able >> to abort it and find myself in some ensure block of an crticial >> section of WeakArray finalization?! Trying to quit just hangs the >> image for good. >> BTW, this is on Windows. >> >> Alex >> >> 2010/10/8 Pavel Krivanek <[hidden email]>: >>> Strange... >>> Linux VM 4.0.3.2202 from squeakvm.org worked well and your prebuilt image >>> works with all this three virtual machines. Any idea why? >>> -- Pavel >>> >>> On Fri, Oct 8, 2010 at 10:49 AM, Marcus Denker <[hidden email]> >>> wrote: >>>> >>>> On Oct 8, 2010, at 10:39 AM, Pavel Krivanek wrote: >>>> >>>> > Hmm, this is the result for Linux and >>>> > cogvm 3.9-7 and pharovm 3.10-3 >>>> > >>>> > >>>> >>>> can you try: >>>> >>>> https://gforge.inria.fr/frs/download.php/27589/PharoCore-1.2-12186.zip >>>> >>>> >>>> -- >>>> Marcus Denker -- http://www.marcusdenker.de >>>> INRIA Lille -- Nord Europe. Team RMoD. >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
In reply to this post by Levente Uzonyi-2
2010/10/8 Levente Uzonyi <[hidden email]>:
> On un*x you can send SIGUSR1 to the process of the VM to make it print all > stacks. IIRC Cog uses this signal for another purpose, so it doesn't work > with Cog. I think it's like that: On a vanilla/standard unix vm SIGUSR1 just terminates the vm. With a cog vm you trigger a printAllStacks with that Signal. http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/152001.html Alex _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
.. or you have a very recent OSProcessPlugin and activate SIGUSR1
2010/10/8 Alexander Lazarević <[hidden email]>: > 2010/10/8 Levente Uzonyi <[hidden email]>: >> On un*x you can send SIGUSR1 to the process of the VM to make it print all >> stacks. IIRC Cog uses this signal for another purpose, so it doesn't work >> with Cog. > > I think it's like that: On a vanilla/standard unix vm SIGUSR1 just > terminates the vm. With a cog vm you trigger a printAllStacks with > that Signal. > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/152001.html > > Alex > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Levente Uzonyi-2
2010/10/8 Levente Uzonyi <[hidden email]>:
> On Fri, 8 Oct 2010, Igor Stasenko wrote: > >> 2010/10/8 Alexander Lazarević <[hidden email]>: >> This is reproducible for me if I do: >> >> Gofer new >> squeaksource: 'MetacelloRepository'; >> package: 'ConfigurationOfExternalWebBrowser'; >> load. >> >> (Smalltalk at: #ConfigurationOfExternalWebBrowser) load >> >> Find the error log attached. > > During load , it says that > FFI-Pools.em.2 does not exists. > But i picked ar.1 version and continued, > that save&quit > everything works well > > > It should be FFI-Pools.eem.2. > > > Levente > >> >> Alex >> >> 2010/10/8 Alexander Lazarević <[hidden email]>: >>> >>> Just when I was about to test drive Torstens configuration of >>> ExternalWebBrowser, the image hangs somewhere while loading. I'm able >>> to abort it and find myself in some ensure block of an crticial >>> section of WeakArray finalization?! Trying to quit just hangs the >>> image for good. >>> BTW, this is on Windows. >>> >>> Alex >>> >>> 2010/10/8 Pavel Krivanek <[hidden email]>: >>>> >>>> Strange... >>>> Linux VM 4.0.3.2202 from squeakvm.org worked well and your prebuilt >>>> image >>>> works with all this three virtual machines. Any idea why? >>>> -- Pavel >>>> >>>> On Fri, Oct 8, 2010 at 10:49 AM, Marcus Denker <[hidden email]> >>>> wrote: >>>>> >>>>> On Oct 8, 2010, at 10:39 AM, Pavel Krivanek wrote: >>>>> >>>>> > Hmm, this is the result for Linux and >>>>> > cogvm 3.9-7 and pharovm 3.10-3 >>>>> > >>>>> > >>>>> >>>>> can you try: >>>>> >>>>> https://gforge.inria.fr/frs/download.php/27589/PharoCore-1.2-12186.zip >>>>> >>>>> >>>>> -- >>>>> Marcus Denker -- http://www.marcusdenker.de >>>>> INRIA Lille -- Nord Europe. Team RMoD. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: 12186 image quit problem
|
|
On Fri, 8 Oct 2010, Igor Stasenko wrote:
> 2010/10/8 Levente Uzonyi <[hidden email]>: > On Fri, 8 Oct 2010, Igor Stasenko wrote: > >> 2010/10/8 Alexander Lazarević <[hidden email]>: >> This is reproducible for me if I do: >> >> Gofer new >> squeaksource: 'MetacelloRepository'; >> package: 'ConfigurationOfExternalWebBrowser'; >> load. >> >> (Smalltalk at: #ConfigurationOfExternalWebBrowser) load >> >> Find the error log attached. > > During load , it says that > FFI-Pools.em.2 does not exists. > But i picked ar.1 version and continued, > that save&quit > everything works well > > > It should be FFI-Pools.eem.2. > Maybe I wasn't clear. I tried to say that the configuration should be fixed, because it contains a typo. FFI-Pools.em.2 doesn't exist, it should be FFI-Pools.eem.2. Levente > > Levente > >> >> Alex >> >> 2010/10/8 Alexander Lazarević <[hidden email]>: >>> >>> Just when I was about to test drive Torstens configuration of >>> ExternalWebBrowser, the image hangs somewhere while loading. I'm able >>> to abort it and find myself in some ensure block of an crticial >>> section of WeakArray finalization?! Trying to quit just hangs the >>> image for good. >>> BTW, this is on Windows. >>> >>> Alex >>> >>> 2010/10/8 Pavel Krivanek <[hidden email]>: >>>> >>>> Strange... >>>> Linux VM 4.0.3.2202 from squeakvm.org worked well and your prebuilt >>>> image >>>> works with all this three virtual machines. Any idea why? >>>> -- Pavel >>>> >>>> On Fri, Oct 8, 2010 at 10:49 AM, Marcus Denker <[hidden email]> >>>> wrote: >>>>> >>>>> On Oct 8, 2010, at 10:39 AM, Pavel Krivanek wrote: >>>>> >>>>> > Hmm, this is the result for Linux and >>>>> > cogvm 3.9-7 and pharovm 3.10-3 >>>>> > >>>>> > >>>>> >>>>> can you try: >>>>> >>>>> https://gforge.inria.fr/frs/download.php/27589/PharoCore-1.2-12186.zip >>>>> >>>>> >>>>> -- >>>>> Marcus Denker -- http://www.marcusdenker.de >>>>> INRIA Lille -- Nord Europe. Team RMoD. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: 12186 image quit problem
|
|
In reply to this post by laza
On Fri, 8 Oct 2010, Alexander Lazarević wrote:
> 2010/10/8 Levente Uzonyi <[hidden email]>: >> On un*x you can send SIGUSR1 to the process of the VM to make it print all >> stacks. IIRC Cog uses this signal for another purpose, so it doesn't work >> with Cog. > > I think it's like that: On a vanilla/standard unix vm SIGUSR1 just > terminates the vm. With a cog vm you trigger a printAllStacks with > that Signal. > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/152001.html Levente > > Alex > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: 12186 image quit problem
|
|
Not sure I follow. Is this saying that one chooses between the default console output and printAllStacks(), or is it making printAllStacks() happen in response to the signal and leaving the usual output in place too? I guess another option might be that all stacks get printed instead of just the active process??
________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Levente Uzonyi [[hidden email]] Sent: Friday, October 08, 2010 12:12 PM To: [hidden email] Subject: Re: [Pharo-project] 12186 image quit problem On Fri, 8 Oct 2010, Alexander Lazarević wrote: > 2010/10/8 Levente Uzonyi <[hidden email]>: >> On un*x you can send SIGUSR1 to the process of the VM to make it print all >> stacks. IIRC Cog uses this signal for another purpose, so it doesn't work >> with Cog. > > I think it's like that: On a vanilla/standard unix vm SIGUSR1 just > terminates the vm. With a cog vm you trigger a printAllStacks with > that Signal. > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/152001.html Indeed. Thanks for clarifying. Levente > > Alex > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Igor Stasenko
Igor,
maybe this just passed me by, but is this supposed to work only with some finalization support in the vm? So is PharoCore1.2 only usable with a very recent vm? Which VMMaker version is needed or what does your squeak -version say? In that case I did not say a word! ;) Alex 2010/10/8 Igor Stasenko <[hidden email]>: > 2010/10/8 Pavel Krivanek <[hidden email]>: >> >> On Fri, Oct 8, 2010 at 12:43 PM, Marcus Denker <[hidden email]> >> wrote: >>> >>> On Oct 8, 2010, at 12:39 PM, Pavel Krivanek wrote: >>> >>> > Hi Marcus, >>> > >>> > is that really all what happened between 12172 and 12186? >>> > >>> > update12186 >>> > Issue 3071: fixing timestamp tests >>> > Issue 3068: Non portable SmalltalkImage>>platformName >>> > deprecationWarning >>> > Issue 3063: removing explain >>> > Issue 3039: There should not be any configuration on Core >>> > >>> > It doesn't explain the problems with VM versions and in 12186 I cannot >>> > build the PharoKernel (it hangs without error in unload phase) >>> > >>> No, we loaded: >>> >>> Issue 3002: A new finalization code ready for integration in Pharo >>> http://code.google.com/p/pharo/issues/detail?id=3002 >> >> ok, can you reproduce this on your VM? >> - take prebuilt 12186 >> - run the image with a file as argument that contains: >> SmalltalkImage current snapshot: true andQuit: true. >> - run the image with a file as argument that contains: >> 5 timesRepeat: [Smalltalk garbageCollect]. >> SmalltalkImage current snapshot: false andQuit: true. >> > > The problem is in MCMethodDefinition>>shutdown. > > Saving works, if i change it to: > > shutDown > " WeakArray removeWeakDependent: Definitions." > Definitions := nil. > > Not sure what happens there.. > > Also, it runs without fix, if i do: > > WeakArray restartFinalizationProcess. > 5 timesRepeat: [Smalltalk garbageCollect]. > SmalltalkImage current snapshot: false andQuit: true. > > > >> -- Pavel >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 8 October 2010 19:54, Alexander Lazarević <[hidden email]> wrote:
> Igor, > > maybe this just passed me by, but is this supposed to work only with > some finalization support in the vm? So is PharoCore1.2 only usable > with a very recent vm? Which VMMaker version is needed or what does > your squeak -version say? > In that case I did not say a word! ;) > nope, it should work w/o problems with older vms. It runs w/o problems in windoze with following vms: Smalltalk vmVersion 'Squeak3.10.2 of 11 February 2010 [latest update: #9314]' WeakFinalizationList hasNewFinalization false Smalltalk vmVersion 'Squeak4.1 of 17 April 2010 [latest update: #9957]' WeakFinalizationList hasNewFinalization true > Alex > > 2010/10/8 Igor Stasenko <[hidden email]>: >> 2010/10/8 Pavel Krivanek <[hidden email]>: >>> >>> On Fri, Oct 8, 2010 at 12:43 PM, Marcus Denker <[hidden email]> >>> wrote: >>>> >>>> On Oct 8, 2010, at 12:39 PM, Pavel Krivanek wrote: >>>> >>>> > Hi Marcus, >>>> > >>>> > is that really all what happened between 12172 and 12186? >>>> > >>>> > update12186 >>>> > Issue 3071: fixing timestamp tests >>>> > Issue 3068: Non portable SmalltalkImage>>platformName >>>> > deprecationWarning >>>> > Issue 3063: removing explain >>>> > Issue 3039: There should not be any configuration on Core >>>> > >>>> > It doesn't explain the problems with VM versions and in 12186 I cannot >>>> > build the PharoKernel (it hangs without error in unload phase) >>>> > >>>> No, we loaded: >>>> >>>> Issue 3002: A new finalization code ready for integration in Pharo >>>> http://code.google.com/p/pharo/issues/detail?id=3002 >>> >>> ok, can you reproduce this on your VM? >>> - take prebuilt 12186 >>> - run the image with a file as argument that contains: >>> SmalltalkImage current snapshot: true andQuit: true. >>> - run the image with a file as argument that contains: >>> 5 timesRepeat: [Smalltalk garbageCollect]. >>> SmalltalkImage current snapshot: false andQuit: true. >>> >> >> The problem is in MCMethodDefinition>>shutdown. >> >> Saving works, if i change it to: >> >> shutDown >> " WeakArray removeWeakDependent: Definitions." >> Definitions := nil. >> >> Not sure what happens there.. >> >> Also, it runs without fix, if i do: >> >> WeakArray restartFinalizationProcess. >> 5 timesRepeat: [Smalltalk garbageCollect]. >> SmalltalkImage current snapshot: false andQuit: true. >> >> >> >>> -- Pavel >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: 12186 image quit problem
|
|
In reply to this post by Igor Stasenko
On Fri, Oct 8, 2010 at 5:06 PM, Igor Stasenko <[hidden email]> wrote:
it hangs for me... -- Pavel _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: 12186 image quit problem
|
|
On Fri, Oct 8, 2010 at 7:15 PM, Pavel Krivanek <[hidden email]> wrote:
with the MCMethodDefinition>>shutdown hack it work well -- Pavel _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Pavel Krivanek-3
2010/10/8 Pavel Krivanek <[hidden email]>:
> > > On Fri, Oct 8, 2010 at 5:06 PM, Igor Stasenko <[hidden email]> wrote: >> >> 2010/10/8 Pavel Krivanek <[hidden email]>: >> > Hi Marcus, >> > is that really all what happened between 12172 and 12186? >> > >> > update12186 >> > Issue 3071: fixing timestamp tests >> > Issue 3068: Non portable SmalltalkImage>>platformName deprecationWarning >> > Issue 3063: removing explain >> > Issue 3039: There should not be any configuration on Core >> > It doesn't explain the problems with VM versions and in 12186 I cannot >> > build >> > the PharoKernel (it hangs without error in unload phase) >> > -- Pavel >> > >> please , tell me if it keep hanging after you doing: >> >> WeakArray restartFinalizationProcess. >> >> it seems like a deadlock with WeakArray's FinalizationLock or >> FinalizationSemaphore. > > it hangs for me... hmm. strange. i can't reproduce this anymore (even after taking fresh 12186 image). > -- Pavel > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Pavel Krivanek-3
2010/10/8 Pavel Krivanek <[hidden email]>:
> > > On Fri, Oct 8, 2010 at 7:15 PM, Pavel Krivanek <[hidden email]> > wrote: >> >> >> On Fri, Oct 8, 2010 at 5:06 PM, Igor Stasenko <[hidden email]> wrote: >>> >>> 2010/10/8 Pavel Krivanek <[hidden email]>: >>> > Hi Marcus, >>> > is that really all what happened between 12172 and 12186? >>> > >>> > update12186 >>> > Issue 3071: fixing timestamp tests >>> > Issue 3068: Non portable SmalltalkImage>>platformName >>> > deprecationWarning >>> > Issue 3063: removing explain >>> > Issue 3039: There should not be any configuration on Core >>> > It doesn't explain the problems with VM versions and in 12186 I cannot >>> > build >>> > the PharoKernel (it hangs without error in unload phase) >>> > -- Pavel >>> > >>> please , tell me if it keep hanging after you doing: >>> >>> WeakArray restartFinalizationProcess. >>> >>> it seems like a deadlock with WeakArray's FinalizationLock or >>> FinalizationSemaphore. >> >> it hangs for me... >> -- Pavel > > with the MCMethodDefinition>>shutdown hack it work well so, at least we know what causing it. Now i wonder, what may cause that WeakArray classPool at: #FinalizationLock get locked by some other process and not released anymore? > -- Pavel > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: 12186 image quit problem
|
|
In reply to this post by Pavel Krivanek-3
Igor
Is it also related to http://code.google.com/p/pharo/issues/detail?id=3048 too? Stef >>>>> with the MCMethodDefinition>>shutdown hack it work well > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 9 October 2010 09:02, Stéphane Ducasse <[hidden email]> wrote:
> Igor > > Is it also related to > http://code.google.com/p/pharo/issues/detail?id=3048 > too? > related? not quite. However by fixing it we at least hide the problem. Somehow , removing weakdependent during shutdown leads to semaphore deadlock. But i don't think that it exactly because MCMethodDefinition registers weakdependent. It could be any other thing, which registers weakdependent and then tries to remove it from weakdependents during shutdown. It also quite hard to reproduce. I was able to lock image few times using script , which Pavel provided. But then running same image with same VM again, didn't lead to lock. > Stef > >>>>>> with the MCMethodDefinition>>shutdown hack it work well >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: 12186 image quit problem
|
|
On Sat, 9 Oct 2010, Igor Stasenko wrote: > On 9 October 2010 09:02, Stéphane Ducasse <[hidden email]> wrote: > Igor > > Is it also related to > http://code.google.com/p/pharo/issues/detail?id=3048 > too? > related? not quite. However by fixing it we at least hide the problem. Somehow , removing weakdependent during shutdown leads to semaphore deadlock. But i don't think that it exactly because MCMethodDefinition registers weakdependent. It could be any other thing, which registers weakdependent and then tries to remove it from weakdependents during shutdown. It also quite hard to reproduce. I was able to lock image few times using script , which Pavel provided. But then running same image with same VM again, didn't lead to lock. It's probably easy to find the cause of the deadlock if you're able to print the stacks. Levente > Stef > >>>>>> with the MCMethodDefinition>>shutdown hack it work well >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: 12186 image quit problem
|
|
In reply to this post by Igor Stasenko
Sig,
Ignore this if you see fit; it might not apply, but don't dismiss it too quickly - it will apply somewhere, somehow. First, are these things happening on shutdown, or on image save? I ask because while they seem to be getting straightened out over time, those concepts have long been intermingled to disadvantage that appears to be greatly underestimated. The correct solution to many startup/shtudown cleanup takes some adjustment. Image save is nothing - ignore it. Shutdown can almost be ignored, though it is wise and polite to try to clean up external resources, and we should have good tools for developers wanting/needing to do so in their own programs. A good OS will clean up resources when something quits, but Andreas and others would point out that there might not be an OS, or it might have been written in the north western US :) The real house cleaning magic happens on startup - all the stuff you bravely ignored on save is now, finally, junk and needs to be discarded. By following this approach, an image save is no big deal, the system does the best it can to clean up after itself on shutdown, and things that were retained post-save (because the image needs to be able to plod along as though nothing happened) get chopped out early in startup and lazily recreated when appropriate. Bill ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]] Sent: Saturday, October 09, 2010 11:38 AM To: [hidden email] Subject: Re: [Pharo-project] 12186 image quit problem On 9 October 2010 09:02, Stéphane Ducasse <[hidden email]> wrote: > Igor > > Is it also related to > http://code.google.com/p/pharo/issues/detail?id=3048 > too? > related? not quite. However by fixing it we at least hide the problem. Somehow , removing weakdependent during shutdown leads to semaphore deadlock. But i don't think that it exactly because MCMethodDefinition registers weakdependent. It could be any other thing, which registers weakdependent and then tries to remove it from weakdependents during shutdown. It also quite hard to reproduce. I was able to lock image few times using script , which Pavel provided. But then running same image with same VM again, didn't lead to lock. > Stef > >>>>>> with the MCMethodDefinition>>shutdown hack it work well >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Sat, Oct 9, 2010 at 2:05 PM, Schwab,Wilhelm K <[hidden email]> wrote: Sig, But remember it is far more efficient in start-up time to use a weak collection of objects that need to be junked/voided/finalized than an allInstancesDo: or two. I made VisualWorks start up about 4 times quicker by e.g. keeping font instances in a collection for voiding their handles on start-up.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: 12186 image quit problem
|
|
No argument there. You might have had better weak collections to work with, but hopefully things like Cog and Sig's finalization improvements will give us similar advantages. Either way, it is important to have good session start/stop awareness and to sever ties at the right time (and to not do so at the wrong times).
________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Eliot Miranda [[hidden email]] Sent: Saturday, October 09, 2010 5:24 PM To: [hidden email] Subject: Re: [Pharo-project] 12186 image quit problem On Sat, Oct 9, 2010 at 2:05 PM, Schwab,Wilhelm K <[hidden email]<mailto:[hidden email]>> wrote: Sig, Ignore this if you see fit; it might not apply, but don't dismiss it too quickly - it will apply somewhere, somehow. First, are these things happening on shutdown, or on image save? I ask because while they seem to be getting straightened out over time, those concepts have long been intermingled to disadvantage that appears to be greatly underestimated. The correct solution to many startup/shtudown cleanup takes some adjustment. Image save is nothing - ignore it. Shutdown can almost be ignored, though it is wise and polite to try to clean up external resources, and we should have good tools for developers wanting/needing to do so in their own programs. A good OS will clean up resources when something quits, but Andreas and others would point out that there might not be an OS, or it might have been written in the north western US :) The real house cleaning magic happens on startup - all the stuff you bravely ignored on save is now, finally, junk and needs to be discarded. By following this approach, an image save is no big deal, the system does the best it can to clean up after itself on shutdown, and things that were retained post-save (because the image needs to be able to plod along as though nothing happened) get chopped out early in startup and lazily recreated when appropriate. But remember it is far more efficient in start-up time to use a weak collection of objects that need to be junked/voided/finalized than an allInstancesDo: or two. I made VisualWorks start up about 4 times quicker by e.g. keeping font instances in a collection for voiding their handles on start-up. Bill ________________________________________ From: [hidden email]<mailto:[hidden email]> [[hidden email]<mailto:[hidden email]>] On Behalf Of Igor Stasenko [[hidden email]<mailto:[hidden email]>] Sent: Saturday, October 09, 2010 11:38 AM To: [hidden email]<mailto:[hidden email]> Subject: Re: [Pharo-project] 12186 image quit problem On 9 October 2010 09:02, Stéphane Ducasse <[hidden email]<mailto:[hidden email]>> wrote: > Igor > > Is it also related to > http://code.google.com/p/pharo/issues/detail?id=3048 > too? > related? not quite. However by fixing it we at least hide the problem. Somehow , removing weakdependent during shutdown leads to semaphore deadlock. But i don't think that it exactly because MCMethodDefinition registers weakdependent. It could be any other thing, which registers weakdependent and then tries to remove it from weakdependents during shutdown. It also quite hard to reproduce. I was able to lock image few times using script , which Pavel provided. But then running same image with same VM again, didn't lead to lock. > Stef > >>>>>> with the MCMethodDefinition>>shutdown hack it work well >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email]<mailto:[hidden email]> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email]<mailto:[hidden email]> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email]<mailto:[hidden email]> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |