Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(
Hi Ronie, On Tue, Mar 14, 2017 at 5:08 PM, Ronie Salgado wrote: > Hi Alex, > > I gave the following script: > > Smalltalk compiler evaluate: ' >> | surface | >> surface := AthensCairoSurface extent: 640@480. >> surface drawDuring: [ :canvas | >> surface clear: Color blue. >> ]. >> >> surface asForm asMorph openInWindow >> ' >> > > Notice that I am wrapping the script in a string that I am passing to the > compiler, so that the workspace cannot retain any reference to the surface. > Can you experiment with VMs at or later than VMMaker.oscog-eem.2156? I added a solution to the BitBlt primitives to detect GC occurring in a BitBlt primitive and for the Cairo surface callbacks returning errors. This is orthogonal to the GC issue you raise, but both issues need solutions. Hopefully we have them now. Another thing to note is that in my latest commit of the entire tree I modified the surface plugin to allow defaulting some of the functions (those for ioGetSurfaceFormat, isUnlockSurface & ioShowSurface), this means that one can default the null callbacks created in createShowSurfaceFn & createUnlockSurfaceFn to answer 0 (provided you change the installation code suitably to not send thunk when the argument is 0, not a Callback). This should speed up small Athens blits noticeably. > Best regards, > Ronie > > 2017-03-14 16:12 GMT-03:00 Alexandre Bergel : > >> Hi Ronie, >> >> Below you said: >> >> The problem with asForm, is that the form returned can be used after the >> cairo surface which holds the pixels is garbage collected. >> >> >> I cannot reproduce this case. You gave a script: >> >> surface := AthensCairoSurface extent: 640@480. >> surface drawDuring: [ :canvas | >> surface clear: Color blue. >> ]. >> >> surface asForm asMorph openInWindow >> >> >> I see a blue window. >> >> Cheers, >> Alexandre >> >> >> How about changing AthensCairoSurface >> asForm into the following >> definition?: >> asForm >> >> "create a form and copy an image data there" >> | form | >> self checkSession. >> >> self flush. >> form := Form extent: (self width@self height) depth: 32. >> form unhibernate. >> LibC memCopy: self getDataPtr to: form bits size: self width*self >> height*4. >> ^ form >> >> This involves a whole copy, but it removes completely the dependency on >> the surface plugin. >> >> If we want to keep using the surface plugin with Cairo, the old >> definition of asForm still has a bug, which can be reproduced with the >> following snippet: >> >> Smalltalk compiler evaluate: ' >> | surface | >> surface := AthensCairoSurface extent: 640@480. >> surface drawDuring: [ :canvas | >> surface clear: Color blue. >> ]. >> >> surface asForm asMorph openInWindow >> ' >> >> The problem with asForm, is that the form returned can be used after the >> cairo surface which holds the pixels is garbage collected. >> >> >> > -- _,,,^..^,,,_ best, Eliot
Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(
Hi Alex, I gave the following script: Smalltalk compiler evaluate: ' > | surface | > surface := AthensCairoSurface extent: 640@480. > surface drawDuring: [ :canvas | > surface clear: Color blue. > ]. > > surface asForm asMorph openInWindow > ' > Notice that I am wrapping the script in a string that I am passing to the compiler, so that the workspace cannot retain any reference to the surface. Best regards, Ronie 2017-03-14 16:12 GMT-03:00 Alexandre Bergel : > Hi Ronie, > > Below you said: > > The problem with asForm, is that the form returned can be used after the > cairo surface which holds the pixels is garbage collected. > > > I cannot reproduce this case. You gave a script: > > surface := AthensCairoSurface extent: 640@480. > surface drawDuring: [ :canvas | > surface clear: Color blue. > ]. > > surface asForm asMorph openInWindow > > > I see a blue window. > > Cheers, > Alexandre > > > How about changing AthensCairoSurface >> asForm into the following > definition?: > asForm > > "create a form and copy an image data there" > | form | > self checkSession. > > self flush. > form := Form extent: (self width@self height) depth: 32. > form unhibernate. > LibC memCopy: self getDataPtr to: form bits size: self width*self > height*4. > ^ form > > This involves a whole copy, but it removes completely the dependency on > the surface plugin. > > If we want to keep using the surface plugin with Cairo, the old definition > of asForm still has a bug, which can be reproduced with the following > snippet: > > Smalltalk compiler evaluate: ' > | surface | > surface := AthensCairoSurface extent: 640@480. > surface drawDuring: [ :canvas | > surface clear: Color blue. > ]. > > surface asForm asMorph openInWindow > ' > > The problem with asForm, is that the form returned can be used after the > cairo surface which holds the pixels is garbage collected. > > >
Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(
Hi Ronie, Below you said: > The problem with asForm, is that the form returned can be used after the > cairo surface which holds the pixels is garbage collected. I cannot reproduce this case. You gave a script: > surface := AthensCairoSurface extent: 640@480. > surface drawDuring: [ :canvas | > surface clear: Color blue. > ]. > > surface asForm asMorph openInWindow I see a blue window. Cheers, Alexandre > How about changing AthensCairoSurface >> asForm into the following > definition?: > asForm > > "create a form and copy an image data there" > | form | > self checkSession. > > self flush. > form := Form extent: (self width@self height) depth: 32. > form unhibernate. > LibC memCopy: self getDataPtr to: form bits size: self width*self > height*4. > ^ form > > This involves a whole copy, but it removes completely the dependency on the > surface plugin. > > If we want to keep using the surface plugin with Cairo, the old definition of > asForm still has a bug, which can be reproduced with the following snippet: > > Smalltalk compiler evaluate: ' > | surface | > surface := AthensCairoSurface extent: 640@480. > surface drawDuring: [ :canvas | > surface clear: Color blue. > ]. > > surface asForm asMorph openInWindow > ' > > The problem with asForm, is that the form returned can be used after the > cairo surface which holds the pixels is garbage collected.
Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(
First option is clean but there is no way to get the surface back to do further things. Second keeps the surface around and this is pretty useful and the class name implies there is something about Athens in there. Now can't we have it both ways? By default it is the second option but when we, say, #withoutCairoDependency, we get the version 1 executed. and a #isCairoIndependent testing thing. anAthensCairoSurfaceForm asForm withoutCairoDependency -> aMundaneForm Phil On Mon, Feb 13, 2017 at 1:48 AM, Ronie Salgado wrote: > Hi, > > How about changing AthensCairoSurface >> asForm into the following > definition?: > asForm > > "create a form and copy an image data there" > | form | > self checkSession. > > self flush. > form := Form extent: (self width@self height) depth: 32. > form unhibernate. > LibC memCopy: self getDataPtr to: form bits size: self width*self > height*4. > ^ form > > This involves a whole copy, but it removes completely the dependency on > the surface plugin. > > If we want to keep using the surface plugin with Cairo, the old definition > of asForm still has a bug, which can be reproduced with the following > snippet: > > Smalltalk compiler evaluate: ' > | surface | > surface := AthensCairoSurface extent: 640@480. > surface drawDuring: [ :canvas | > surface clear: Color blue. > ]. > > surface asForm asMorph openInWindow > ' > > The problem with asForm, is that the form returned can be used after the > cairo surface which holds the pixels is garbage collected. The solution to > that problem, is the following (attached): > asForm > > "create a form and copy an image data there" > self checkSession. > > self flush. > ^ (AthensCairoSurfaceForm extent: (self width@self height) depth: 32 > bits: id) > surface: self; > yourself > > Where AthensCairoSurfaceForm(attached) is just a subclass of Form, that > holds a reference to the surface object that manages the lifetime of the > pixels referenced by the bits in the form. By having an extra reference to > the surface, we can prevent the finalization of it, until is not being > referenced by a form that uses its storage. > > Best regards, > Ronie > > 2016-12-21 5:27 GMT-03:00 Esteban Lorenzano : > >> would be possible to have one of your crashing images? >> so I can test… because one of my problems is that I’m not able to >> reproduce the problem when I try, and is hard to fix blindly... >> >> Esteban >> >> > On 21 Dec 2016, at 08:09, Alexandre Bergel >> wrote: >> > >> > I had plenty of elements in my Roassal visualization, and on some point >> it just crashed. >> > I have the impression that having many elements and / or animations (as >> in the case of Johan Fabry) triggers the crash. >> > >> > Alexandre >> > >> > >> >> On Dec 20, 2016, at 9:12 AM, Stephane Ducasse >> wrote: >> >> >> >> So what was your crash problem? >> >> >> >> >> >> On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel < >> alexandre.ber...@me.com> wrote: >> >>> so did it work? >> >>> Is there something that we should do? >> >> >> >> I had no problem, but as Henrik and Peter said, the problem is likely >> to be more complex >> >> >> >> Alexandre >> >> >> >> >> >>> >> >>> On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel < >> alexandre.ber...@me.com> wrote: >> >>> Okay, trying… >> >>> >> >>> Alexandre >> >>> >> >>> >> On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel >> 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.ber...@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-...@list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> >> >>> >> >>> -- >> >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >>> Alexandre Bergel http://www.bergel.eu >> >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >>> >> >>> >> >>> >> >>> >> >>> >> >> >> >> -- >> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >> Alexandre Bergel http://www.bergel.eu >> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >> >> >> >> > >> > -- >> > _,.;:~^~:;._,.;:~^
Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(
Hi, How about changing AthensCairoSurface >> asForm into the following definition?: asForm "create a form and copy an image data there" | form | self checkSession. self flush. form := Form extent: (self width@self height) depth: 32. form unhibernate. LibC memCopy: self getDataPtr to: form bits size: self width*self height*4. ^ form This involves a whole copy, but it removes completely the dependency on the surface plugin. If we want to keep using the surface plugin with Cairo, the old definition of asForm still has a bug, which can be reproduced with the following snippet: Smalltalk compiler evaluate: ' | surface | surface := AthensCairoSurface extent: 640@480. surface drawDuring: [ :canvas | surface clear: Color blue. ]. surface asForm asMorph openInWindow ' The problem with asForm, is that the form returned can be used after the cairo surface which holds the pixels is garbage collected. The solution to that problem, is the following (attached): asForm "create a form and copy an image data there" self checkSession. self flush. ^ (AthensCairoSurfaceForm extent: (self width@self height) depth: 32 bits: id) surface: self; yourself Where AthensCairoSurfaceForm(attached) is just a subclass of Form, that holds a reference to the surface object that manages the lifetime of the pixels referenced by the bits in the form. By having an extra reference to the surface, we can prevent the finalization of it, until is not being referenced by a form that uses its storage. Best regards, Ronie 2016-12-21 5:27 GMT-03:00 Esteban Lorenzano : > would be possible to have one of your crashing images? > so I can test… because one of my problems is that I’m not able to > reproduce the problem when I try, and is hard to fix blindly... > > Esteban > > > On 21 Dec 2016, at 08:09, Alexandre Bergel > wrote: > > > > I had plenty of elements in my Roassal visualization, and on some point > it just crashed. > > I have the impression that having many elements and / or animations (as > in the case of Johan Fabry) triggers the crash. > > > > Alexandre > > > > > >> On Dec 20, 2016, at 9:12 AM, Stephane Ducasse > wrote: > >> > >> So what was your crash problem? > >> > >> > >> On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel < > alexandre.ber...@me.com> wrote: > >>> so did it work? > >>> Is there something that we should do? > >> > >> I had no problem, but as Henrik and Peter said, the problem is likely > to be more complex > >> > >> Alexandre > >> > >> > >>> > >>> On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel < > alexandre.ber...@me.com> wrote: > >>> Okay, trying… > >>> > >>> Alexandre > >>> > >>> > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel > 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.ber...@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-...@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > >>> > >>> -- > >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>> Alexandre Bergel http://www.bergel.eu > >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>> > >>> > >>> > >>> > >>> > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >> > >> > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > AthensCairoSurface-asForm.st Description: Binary data AthensCairoSurfaceForm.st Description: Binary data
Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(
would be possible to have one of your crashing images? so I can test… because one of my problems is that I’m not able to reproduce the problem when I try, and is hard to fix blindly... Esteban > On 21 Dec 2016, at 08:09, Alexandre Bergel wrote: > > I had plenty of elements in my Roassal visualization, and on some point it > just crashed. > I have the impression that having many elements and / or animations (as in > the case of Johan Fabry) triggers the crash. > > Alexandre > > >> On Dec 20, 2016, at 9:12 AM, Stephane Ducasse >> wrote: >> >> So what was your crash problem? >> >> >> On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel >> wrote: >>> so did it work? >>> Is there something that we should do? >> >> I had no problem, but as Henrik and Peter said, the problem is likely to be >> more complex >> >> Alexandre >> >> >>> >>> On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel >>> wrote: >>> Okay, trying… >>> >>> Alexandre >>> >>> On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel 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 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-...@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >
Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(
Hi Nicolai, Thanks for the explanation! Peter said that his fix works for Windows. Why would this fix only work for Windows? And what can we do for other platforms? Cheers, Doru > On Dec 21, 2016, at 8:48 AM, Nicolai Hess wrote: > > > > Am 21.12.2016 8:10 vorm. schrieb "Alexandre Bergel" : > I had plenty of elements in my Roassal visualization, and on some point it > just crashed. > I have the impression that having many elements and / or animations (as in > the case of Johan Fabry) triggers the crash. > > > One problem, the one peter (partly) fixed, is n issue with bitblt, Cairo (as > a surface plugin) and garbage collection. > Bitblt my call the surface plugin to request some information about the Form. > NB-based ffi for Cairo just called gen. asm code. But with UFFI, we now > callback to Smalltalk code, which may trigger a GC. > So every time bitblt, makes a call to the surface plugin (Cairo) and this > callback allocates a new ST-Object, the GC may run and moves(!)the objects, > to which bitblt still holds a reference. > Accessing this objects in bitblt, after the callback returns (may) result in > a segfault. > Depending on the concrete bltoperation, the object memory layout, the size(!) > of the initial Cairo surface. > With peters fix/hack, the code does not crash but it still may access and > operates on moved objects. > Pining the objects may help, but you need to know where in the (vm image) > code a form is used for drawing, and if it is a real form or external data > managed by the surface plugin. > And of course, when to "unpin" the object. > > A saver way would be, to just disable any GC during the executing of the > callback, if it was called by a plugin (here:bitblt) > > > > Alexandre > > > > On Dec 20, 2016, at 9:12 AM, Stephane Ducasse > > wrote: > > > > So what was your crash problem? > > > > > > On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel > > wrote: > > > so did it work? > > > Is there something that we should do? > > > > I had no problem, but as Henrik and Peter said, the problem is likely to be > > more complex > > > > Alexandre > > > > > > > > > > On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel > > > wrote: > > > Okay, trying… > > > > > > Alexandre > > > > > > > > > > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel > > > > 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 > > > > 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-...@list.inf.unibe.ch > > > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > > > > > > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."
Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(
Am 21.12.2016 8:10 vorm. schrieb "Alexandre Bergel" : I had plenty of elements in my Roassal visualization, and on some point it just crashed. I have the impression that having many elements and / or animations (as in the case of Johan Fabry) triggers the crash. One problem, the one peter (partly) fixed, is n issue with bitblt, Cairo (as a surface plugin) and garbage collection. Bitblt my call the surface plugin to request some information about the Form. NB-based ffi for Cairo just called gen. asm code. But with UFFI, we now callback to Smalltalk code, which may trigger a GC. So every time bitblt, makes a call to the surface plugin (Cairo) and this callback allocates a new ST-Object, the GC may run and moves(!)the objects, to which bitblt still holds a reference. Accessing this objects in bitblt, after the callback returns (may) result in a segfault. Depending on the concrete bltoperation, the object memory layout, the size(!) of the initial Cairo surface. With peters fix/hack, the code does not crash but it still may access and operates on moved objects. Pining the objects may help, but you need to know where in the (vm image) code a form is used for drawing, and if it is a real form or external data managed by the surface plugin. And of course, when to "unpin" the object. A saver way would be, to just disable any GC during the executing of the callback, if it was called by a plugin (here:bitblt) Alexandre > On Dec 20, 2016, at 9:12 AM, Stephane Ducasse wrote: > > So what was your crash problem? > > > On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel wrote: > > so did it work? > > Is there something that we should do? > > I had no problem, but as Henrik and Peter said, the problem is likely to be more complex > > Alexandre > > > > > > On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel < alexandre.ber...@me.com> wrote: > > Okay, trying… > > > > Alexandre > > > > > > > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel 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.ber...@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-...@list.inf.unibe.ch > > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(
Just to make clear, I am using the latest VM on Mac OS X, El capitan, latest Pharo. The crashes I experienced are not new. My original email was not a complain (even if it may be perceived as one), but more to trigger a discussion. Peter did an excellent report of the current state of this issue. Cheers, Alexandre > On Dec 16, 2016, at 4:34 PM, Alexandre Bergel 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-...@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(
I had plenty of elements in my Roassal visualization, and on some point it just crashed. I have the impression that having many elements and / or animations (as in the case of Johan Fabry) triggers the crash. Alexandre > On Dec 20, 2016, at 9:12 AM, Stephane Ducasse wrote: > > So what was your crash problem? > > > On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel > wrote: > > so did it work? > > Is there something that we should do? > > I had no problem, but as Henrik and Peter said, the problem is likely to be > more complex > > Alexandre > > > > > > On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel > > wrote: > > Okay, trying… > > > > Alexandre > > > > > > > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel 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 > > > 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-...@list.inf.unibe.ch > > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(
FreeType crashes are different, and I do experience them ocassionally (unlike Roassal ones), but they should be discussed in another thread. Peter On Tue, Dec 20, 2016 at 12:46:30PM +0100, p...@highoctane.be wrote: > Clement told me that a number of these crashes have been solved eons ago in > the opensmalltalkvm and that we are lagging behind with the integration of > these things. > > I am a clueless n00b on what this was about, so, what is the exact status? > I possibly face the same kind of issues in other areas and have been using > a Windows VM with StrikeFonts to have it stable. > > Phil > > > > > On Tue, Dec 20, 2016 at 9:12 AM, Stephane Ducasse > wrote: > > > So what was your crash problem? > > > > > > On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel > > wrote: > > > >> > so did it work? > >> > Is there something that we should do? > >> > >> I had no problem, but as Henrik and Peter said, the problem is likely to > >> be more complex > >> > >> Alexandre > >> > >> > >> > > >> > On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel < > >> alexandre.ber...@me.com> wrote: > >> > Okay, trying… > >> > > >> > Alexandre > >> > > >> > > >> > > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel > >> 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.ber...@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-...@list.inf.unibe.ch > >> > > https://www.list.inf.unibe.ch/listinfo/moose-dev > >> > > > >> > > > >> > > >> > -- > >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> > Alexandre Bergel http://www.bergel.eu > >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > > >> > > >> > > >> > > >> > > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >> > >> > >
Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(
Clement told me that a number of these crashes have been solved eons ago in the opensmalltalkvm and that we are lagging behind with the integration of these things. I am a clueless n00b on what this was about, so, what is the exact status? I possibly face the same kind of issues in other areas and have been using a Windows VM with StrikeFonts to have it stable. Phil On Tue, Dec 20, 2016 at 9:12 AM, Stephane Ducasse wrote: > So what was your crash problem? > > > On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel > wrote: > >> > so did it work? >> > Is there something that we should do? >> >> I had no problem, but as Henrik and Peter said, the problem is likely to >> be more complex >> >> Alexandre >> >> >> > >> > On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel < >> alexandre.ber...@me.com> wrote: >> > Okay, trying… >> > >> > Alexandre >> > >> > >> > > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel >> 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.ber...@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-...@list.inf.unibe.ch >> > > https://www.list.inf.unibe.ch/listinfo/moose-dev >> > > >> > > >> > >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> > >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >
Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(
So what was your crash problem? On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel wrote: > > so did it work? > > Is there something that we should do? > > I had no problem, but as Henrik and Peter said, the problem is likely to > be more complex > > Alexandre > > > > > > On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel < > alexandre.ber...@me.com> wrote: > > Okay, trying… > > > > Alexandre > > > > > > > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel > 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.ber...@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-...@list.inf.unibe.ch > > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >
Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(
> so did it work? > Is there something that we should do? I had no problem, but as Henrik and Peter said, the problem is likely to be more complex Alexandre > > On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel > wrote: > Okay, trying… > > Alexandre > > > > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel 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 > > 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-...@list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(
Wow! Wonderful experience report! Alexandre > On Dec 19, 2016, at 2:03 PM, Peter Uhnak 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 > ___ > Moose-dev mailing list > moose-...@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(
Using floats should not be a problem as BitBlt will round these to integers: | canvas image | canvas := FormCanvas extent: 100.1@100.2. canvas fillColor: Color gray. image := Smalltalk ui icons iconNamed: #error. canvas image: image at: 2.5@3.9 sourceRect: (1.2@5.3 extent: 42.1@43.4) rule: 34. canvas form inspect. Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Stephane Ducasse Sent: Monday, December 19, 2016 10:09 PM To: Pharo Development List 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 mailto:alexandre.ber...@me.com>> wrote: Okay, trying… Alexandre > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel > mailto:alex.sy...@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 > mailto:alexandre.ber...@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-...@list.inf.unibe.ch<mailto:moose-...@list.inf.unibe.ch> > https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 wrote: > Okay, trying… > > Alexandre > > > > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel > 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 > 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-...@list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >
Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(
Okay, trying… Alexandre > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel 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 > 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-...@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(
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 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-...@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > >