Hi Ronie, Esteban. Ronie's suggestion in the form Esteban presented it helped. After implementing the fix I failed to crash my application any more.
Will anybody be so kind to explain me what actually happens and why the fix works? It looks so innocent. As far as I understand we do one additional copy. But I do not understand why it prevents from accessing beyond the memory bounds. Thank you, Alex On Wed, Mar 1, 2017 at 8:24 AM, Igor Stasenko <siguc...@gmail.com> wrote: > > > On 1 March 2017 at 05:42, Alexander Samoylovich <samoylov...@gmail.com> > wrote: > >> Thanks everybody for the explanation. >> >> I tried to apply Igor's suggestion. I allocate an offscreen surface 1 row >> larger than needed >> and when converting discard one row. >> >> The code looks more stable now. The test was up for about 30 minutes >> before crashing instead of 1 minute before the fix. >> Is it the right code change or just a coincidence? >> >> >> AthensCairoSurface>>asForm >> >> >> "create a form and copy an image data there" >> >> self checkSession. >> >> self flush. >> >> ^ Form extent: (self width@self height) - (0@1) depth: 32 bits: id >> >> > no, it isn't . This is how it supposed to be there. > But the problem is when you using surfaces for bitmaps in Cairo itself, > you're screwed since AthensCairoSurface purposedly makes it 1 row taller, > while for texture you want it to contain exact height, else you'll > obviously have artifacts. :( > > So, the point is: if you creating a surface that will be used by bitblt > (asForm), then you should allocate 1 extra row, > else you shouldn't.. And there's no workaround to match such behavior in > single class, > since it doesn't knows what it will be used for :( > > >> >> On Mon, Feb 27, 2017 at 2:39 PM, Stephane Ducasse < >> stepharo.s...@gmail.com> wrote: >> >>> Tx igor I added >>> >>> https://pharo.fogbugz.com/f/cases/19764/Improve-comment-of-A >>> thensCairoSurfaceForm >>> >>> On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <siguc...@gmail.com> >>> wrote: >>> >>>> and i was dealing with it by adding 1 extra line to cairo surface, >>>> but reporting 1 less to Form. Like so, bitblt still reads past the >>>> allowed size, but it is safe, because there are unused bit(s). >>>> >>>> On 27 February 2017 at 20:31, Igor Stasenko <siguc...@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On 27 February 2017 at 12:29, Esteban Lorenzano <esteba...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> the problem wit Ronie’s fix is that (as he says) you are copying >>>>>> another time the surface, before passing it to the VM (who makes >>>>>> yet-another-copy) so this is not optimal… and you can see it when running >>>>>> the Tiger demo: there are a lot of pauses. >>>>>> So I would prefer the other approach he suggests: >>>>>> >>>>>> Form subclass: #AthensCairoSurfaceForm >>>>>> instanceVariableNames: 'surface' >>>>>> classVariableNames: '' >>>>>> package: 'Athens-Cairo' >>>>>> >>>>>> AthensCairoSurfaceForm>>surface >>>>>> ^ surface >>>>>> >>>>>> AthensCairoSurfaceForm>>surface: anObject >>>>>> surface := anObject >>>>>> >>>>>> AthensCairoSurface>>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 >>>>>> >>>>>> that seems to work. Can you try and see? >>>>>> >>>>>> >>>>> Btw, remember the culprit there , that you must have extra word in >>>>> trailing buffer space, >>>>> this is because bit-blt using read-ahead . Which is OK for objects >>>>> located in object memory, >>>>> since there are always something past the last object (unallocated >>>>> space), >>>>> but not so ok for buffers allocated by malloc (such as cairo surface >>>>> bitmap), and so, >>>>> if you read even a single byte past it, you get protection fault. >>>>> >>>>> >>>>>> Esteban >>>>>> >>>>>> > On 24 Feb 2017, at 15:47, stepharong <stephar...@free.fr> wrote: >>>>>> > >>>>>> > Hi alex >>>>>> > >>>>>> > can you try the fix of ronie and let us know if it makes roassal >>>>>> more stable? >>>>>> > >>>>>> > Stef >>>>>> > >>>>>> >> Dear Alexander, >>>>>> >> >>>>>> >> Sine the new FFI of Pharo, using Athens has become unreliable. >>>>>> This is a pity, but fixing this is not trivial at all (we have been >>>>>> trying >>>>>> for years). >>>>>> >> >>>>>> >> What exactly are you doing with Athens? >>>>>> >> >>>>>> >> Alexandre >>>>>> >> >>>>>> >> >>>>>> >>> On Feb 22, 2017, at 12:55 AM, Alexander Samoylovich < >>>>>> samoylov...@gmail.com> wrote: >>>>>> >>> >>>>>> >>> Hello >>>>>> >>> >>>>>> >>> I am writing graphic demo programs using Athens on Mac Sierra. >>>>>> >>> Time by time Pharo VM crashes. Programs not using Athens work >>>>>> reliably. >>>>>> >>> I believe the behavior is reproducible. >>>>>> >>> How should I report a bug? >>>>>> >>> >>>>>> >>> Alex >>>>>> >> >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > Using Opera's mail client: http://www.opera.com/mail/ >>>>>> > >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> > > > -- > Best regards, > Igor Stasenko. >
