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

Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(

by Alexandre Bergel

Wow! Wonderful experience report! Alexandre > On Dec 19, 2016, at 2:03 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > On Mon, Dec 19, 2016 at 08:12:29AM +0800, Ben Coman wrote: >> Can yo point to where you added you workaround? > > The fix is a single line, because I hate myself. > > interpreterProxy failed ifTrue:[^nil]. > > https://github.com/pharo-project/pharo-vm/commit/9bf66cf656b176d988e1b0ba74… > > To give you more info: > > The problem is that memory of canvas forms are not properly pinned, so during garbage collection the form is being moved, but if at the same time the canvas form is being updated and moved, you are accessing wrong memory -> crash. > > My fix will return prematurely if an error occurs and throws PrimitiveFailed in the image before any wrong memory is accessed. On Roassal side the PrimitiveFailed is catched and a paint cycle is skipped --- this is good enough, as it results only in ocassional flicker that immediately fixes itself instead of crashing the image. > > It seems that on Mac there are also other places in the BitBlt code where the surface is being accessed without a check. > > Also be careful not to be misled by the crash dump stack. It took me quite a while to figure out that GrafPort is already operating on wrong data, so it's not GrafPort's fault, but BitBlt's; of course both should possibly be investigated with respect to the mac crash. > > Final note, personally I found it much easier the debug and manipulate the resulting C code (and recompiling just that), then to modify the Slang code and rebuild the source code and recompile it all (but again, I don't know what is the proper way to work with the VM code). > > I used this script to trigger the crash https://gist.github.com/peteruhnak/024650ed2594301558df4da913549b54 > As the crash depends on memory consumption and "proper" garbage collection cycle, it wasn't the easiest to reproduce, however the script above usually managed to crash it. Having a more reliable way would be nice, but simply triggering GC (nor full GC) wasn't enough because the memory wasn't in the "right" state. > > Peter > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 20, 2016

Re: [Pharo-dev] [Moose-dev] Re: Too frequent crashes :-(

by Alexandre Bergel

Thanks Peter for your email. Alexandre > On Dec 18, 2016, at 10:10 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi Alex, > > I certainly understand your frustration, I felt it too on Windows to the point where I stopped using Pharo for couple of weeks out of rage, and then spend in total at least 40+ hours digging into the VM until I added usable workaround for Windows. Not to mention how frustrating was the fixing it. > > Obviously on Mac there are still some unresolved pathways, but it will not magically fix itself. > > The reason for the crash (bad object pinning and moving of canvas memory) has been known for some time now, so more crash.dmps do not give any more insight. > > If this is to be resolved then one of the two have to happen: > > A) Someone who really understands VM/image memory management / GC / pinning fixes the issue. > > B) Someone with Mac (which I don't have) digs around BitBlt code (or wherever it was) and adds a similar workaround. > > Considering the issue has emerged more than a year ago (Spur switch), I don't think (A) is going to happen any time soon, so I guess the only chance is to get elbows greasy and fix it yourself (B) (or you make one of your students suffer :)). > > I didn't have a single Roassal/BitBlt related crash on Windows since my fix was added, so there should be a way to add a workaround for Mac too. > > (there are of course crashes related to FT, but the story is arguably the same). > > TL;DR: I don't think it's on a todo list of anyone who actually understands this, so the only way to fix it is by yourself or find a concrete person that would be willing to dig into it. > > Peter > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 20, 2016

Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(

by Henrik Nergaard

Using floats should not be a problem as BitBlt will round these to integers: | canvas image | canvas := FormCanvas extent: 100.1(a)100.2. canvas fillColor: Color gray. image := Smalltalk ui icons iconNamed: #error. canvas image: image at: 2.5(a)3.9 sourceRect: (1.2(a)5.3 extent: 42.1(a)43.4) rule: 34. canvas form inspect. Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephane Ducasse Sent: Monday, December 19, 2016 10:09 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-( so did it work? Is there something that we should do? On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel <alexandre.bergel(a)me.com<mailto:alexandre.bergel@me.com>> wrote: Okay, tryingâ¦ Alexandre > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel <alex.syrel(a)gmail.com<mailto:alex.syrel@gmail.com>> wrote: > > According to crash.dmp TRMorph>drawOn: draws an image using FormCanvas>>#image:at:sourceRect:rule: at a coordinate represented by a Float point. > Try to round it to integer point. > > Cheers, > Alex > > On 16 December 2016 at 16:34, Alexandre Bergel <alexandre.bergel(a)me.com<mailto:alexandre.bergel@me.com>> wrote: > Hi! > > Vincent and I are experiencing many crashes from GrafPort>copyBits. It crashes every couple of minutes. > > I know that not much can be done so far. Stability is my biggest concern with Pharo :-( > I use the latest VM. > > Cheers, > Alexandre > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch<mailto:Moose-dev@list.inf.unibe.ch> > https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 19, 2016

Re: [Pharo-dev] About Fraction and parentheses

by Sven Van Caekenberghe

> On 19 Dec 2016, at 22:00, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi serge > > the printing should be normal because like that you are ready to type > 1/3 + 2/3 and get 1. No, not at all: 1/3 + 2/3 "(7/9)" These are all just binary messages evaluated left to right, like this: ((1/3) + 2)/3 "(7/9)" That is why you need the parenthesis in certain contexts. Now adding two of them is definitively wrong. (1/3) + (2/3) "1" (The first parenthesis are not needed, btw). > Now I do not get why you get ((1/2)) thanks for reporting it. > > Stef > > On Mon, Dec 19, 2016 at 9:08 AM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > I have one question about Fraction. > > When I print a fraction like 1/2 in the Playground I obtain (1/2) and > when I inspect I obtain ((1/2)). Why do we need all these parentheses > ? > > I didn't try with a current Pharo 6.0 image, because my bandwidth is > quite limited right now (Vietnam). > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

Dec. 19, 2016

Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(

by Stephane Ducasse

so did it work? Is there something that we should do? On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Okay, tryingâ¦ > > Alexandre > > > > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> > wrote: > > > > According to crash.dmp TRMorph>drawOn: draws an image using > FormCanvas>>#image:at:sourceRect:rule: at a coordinate represented by a > Float point. > > Try to round it to integer point. > > > > Cheers, > > Alex > > > > On 16 December 2016 at 16:34, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > Hi! > > > > Vincent and I are experiencing many crashes from GrafPort>copyBits. It > crashes every couple of minutes. > > > > I know that not much can be done so far. Stability is my biggest concern > with Pharo :-( > > I use the latest VM. > > > > Cheers, > > Alexandre > > > > > > > > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Dec. 19, 2016

Re: [Pharo-dev] About Fraction and parentheses

by Stephane Ducasse

Hi serge the printing should be normal because like that you are ready to type 1/3 + 2/3 and get 1. Now I do not get why you get ((1/2)) thanks for reporting it. Stef On Mon, Dec 19, 2016 at 9:08 AM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > I have one question about Fraction. > > When I print a fraction like 1/2 in the Playground I obtain (1/2) and > when I inspect I obtain ((1/2)). Why do we need all these parentheses > ? > > I didn't try with a current Pharo 6.0 image, because my bandwidth is > quite limited right now (Vietnam). > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

Dec. 19, 2016

Re: [Pharo-dev] [Moose-dev] Re: Too frequent crashes :-(

by Stephane Ducasse

Hi peter I can understand your frustration. I would be really like to see what I can do to help. But I do not know. Except showing your mail to the vm guys. Thanks for having send it! Stef On Mon, Dec 19, 2016 at 2:03 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > On Mon, Dec 19, 2016 at 08:12:29AM +0800, Ben Coman wrote: > > Can yo point to where you added you workaround? > > The fix is a single line, because I hate myself. > > interpreterProxy failed ifTrue:[^nil]. > > https://github.com/pharo-project/pharo-vm/commit/ > 9bf66cf656b176d988e1b0ba74fc37da467e6192 > > To give you more info: > > The problem is that memory of canvas forms are not properly pinned, so > during garbage collection the form is being moved, but if at the same time > the canvas form is being updated and moved, you are accessing wrong memory > -> crash. > > My fix will return prematurely if an error occurs and throws > PrimitiveFailed in the image before any wrong memory is accessed. On > Roassal side the PrimitiveFailed is catched and a paint cycle is skipped > --- this is good enough, as it results only in ocassional flicker that > immediately fixes itself instead of crashing the image. > > It seems that on Mac there are also other places in the BitBlt code where > the surface is being accessed without a check. > > Also be careful not to be misled by the crash dump stack. It took me quite > a while to figure out that GrafPort is already operating on wrong data, so > it's not GrafPort's fault, but BitBlt's; of course both should possibly be > investigated with respect to the mac crash. > > Final note, personally I found it much easier the debug and manipulate the > resulting C code (and recompiling just that), then to modify the Slang code > and rebuild the source code and recompile it all (but again, I don't know > what is the proper way to work with the VM code). > > I used this script to trigger the crash https://gist.github.com/ > peteruhnak/024650ed2594301558df4da913549b54 > As the crash depends on memory consumption and "proper" garbage collection > cycle, it wasn't the easiest to reproduce, however the script above usually > managed to crash it. Having a more reliable way would be nice, but simply > triggering GC (nor full GC) wasn't enough because the memory wasn't in the > "right" state. > > Peter > >

Dec. 19, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 458c6c: 60330

by Max Leske

VM looks ok BTW. Really seems to be the update itself. > On 19 Dec 2016, at 21:00, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hmm.. I think I will revert this update. > >> On 19 Dec 2016, at 16:36, Max Leske <maxleske(a)gmail.com> wrote: >> >> Confirmed on OS X 10.12.3 >> >>> On 19 Dec 2016, at 19:26, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> The image seems to come up with a black screenâ¦ something went wrong. >>> >>> Can someone else check? >>> >>>> On 19 Dec 2016, at 14:21, GitHub <noreply(a)github.com> wrote: >>>> >>>> Branch: refs/heads/6.0 >>>> Home: https://github.com/pharo-project/pharo-core >>>> Commit: 458c6cef0678ceeedd886a7e8c952aa72ceddca0 >>>> https://github.com/pharo-project/pharo-core/commit/458c6cef0678ceeedd886a7e… >>>> Author: Jenkins Build Server <board(a)pharo-project.org> >>>> Date: 2016-12-19 (Mon, 19 Dec 2016) >>>> >>>> Changed paths: >>>> M Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForMilliseconds.st >>>> M Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForSeconds.st >>>> M Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForMilliseconds.st >>>> M Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForSeconds.st >>>> M Kernel.package/Delay.class/class/initialize-release/initialize.st >>>> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60329.st >>>> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60330.st >>>> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60329.st >>>> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60330.st >>>> M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >>>> A SmartSuggestions.package/SugsAbstractContext.class/instance/accessing/model.st >>>> A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectTheTextForTheNode.st >>>> A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectedInterval.st >>>> >>>> Log Message: >>>> ----------- >>>> 60330 >>>> 18735 DNU on suggestions shortcut in GTDebugger >>>> https://pharo.fogbugz.com/f/cases/18735 >>>> >>>> 19432 Promote DelaySpinScheduler from experimental status (part 2) >>>> https://pharo.fogbugz.com/f/cases/19432 >>>> >>>> 19438 Widen tolerance for DelayScheduler timing tests >>>> https://pharo.fogbugz.com/f/cases/19438 >>>> >>>> http://files.pharo.org/image/60/60330.zip >>>> >>>> >>> >>> >> >> > >

Dec. 19, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 458c6c: 60330

by Marcus Denker

Hmm.. I think I will revert this update. > On 19 Dec 2016, at 16:36, Max Leske <maxleske(a)gmail.com> wrote: > > Confirmed on OS X 10.12.3 > >> On 19 Dec 2016, at 19:26, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> The image seems to come up with a black screenâ¦ something went wrong. >> >> Can someone else check? >> >>> On 19 Dec 2016, at 14:21, GitHub <noreply(a)github.com> wrote: >>> >>> Branch: refs/heads/6.0 >>> Home: https://github.com/pharo-project/pharo-core >>> Commit: 458c6cef0678ceeedd886a7e8c952aa72ceddca0 >>> https://github.com/pharo-project/pharo-core/commit/458c6cef0678ceeedd886a7e… >>> Author: Jenkins Build Server <board(a)pharo-project.org> >>> Date: 2016-12-19 (Mon, 19 Dec 2016) >>> >>> Changed paths: >>> M Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForMilliseconds.st >>> M Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForSeconds.st >>> M Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForMilliseconds.st >>> M Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForSeconds.st >>> M Kernel.package/Delay.class/class/initialize-release/initialize.st >>> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60329.st >>> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60330.st >>> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60329.st >>> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60330.st >>> M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >>> A SmartSuggestions.package/SugsAbstractContext.class/instance/accessing/model.st >>> A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectTheTextForTheNode.st >>> A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectedInterval.st >>> >>> Log Message: >>> ----------- >>> 60330 >>> 18735 DNU on suggestions shortcut in GTDebugger >>> https://pharo.fogbugz.com/f/cases/18735 >>> >>> 19432 Promote DelaySpinScheduler from experimental status (part 2) >>> https://pharo.fogbugz.com/f/cases/19432 >>> >>> 19438 Widen tolerance for DelayScheduler timing tests >>> https://pharo.fogbugz.com/f/cases/19438 >>> >>> http://files.pharo.org/image/60/60330.zip >>> >>> >> >> > >

Dec. 19, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 458c6c: 60330

by Max Leske

Confirmed on OS X 10.12.3 > On 19 Dec 2016, at 19:26, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > The image seems to come up with a black screenâ¦ something went wrong. > > Can someone else check? > >> On 19 Dec 2016, at 14:21, GitHub <noreply(a)github.com> wrote: >> >> Branch: refs/heads/6.0 >> Home: https://github.com/pharo-project/pharo-core >> Commit: 458c6cef0678ceeedd886a7e8c952aa72ceddca0 >> https://github.com/pharo-project/pharo-core/commit/458c6cef0678ceeedd886a7e… >> Author: Jenkins Build Server <board(a)pharo-project.org> >> Date: 2016-12-19 (Mon, 19 Dec 2016) >> >> Changed paths: >> M Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForMilliseconds.st >> M Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForSeconds.st >> M Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForMilliseconds.st >> M Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForSeconds.st >> M Kernel.package/Delay.class/class/initialize-release/initialize.st >> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60329.st >> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60330.st >> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60329.st >> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60330.st >> M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >> A SmartSuggestions.package/SugsAbstractContext.class/instance/accessing/model.st >> A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectTheTextForTheNode.st >> A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectedInterval.st >> >> Log Message: >> ----------- >> 60330 >> 18735 DNU on suggestions shortcut in GTDebugger >> https://pharo.fogbugz.com/f/cases/18735 >> >> 19432 Promote DelaySpinScheduler from experimental status (part 2) >> https://pharo.fogbugz.com/f/cases/19432 >> >> 19438 Widen tolerance for DelayScheduler timing tests >> https://pharo.fogbugz.com/f/cases/19438 >> >> http://files.pharo.org/image/60/60330.zip >> >> > >

Dec. 19, 2016