> On 5 Mar 2017, at 05:00, Alexander Samoylovich <samoylov...@gmail.com> wrote: > > 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.
Cairo Surface is GCd if not kept while using it… then your system go BOOM :P that’s why we need to be sure it will not be disposed before it’s time (hence we kept it in the form that needs to be displayed). Esteban > > 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 > <mailto:siguc...@gmail.com>> wrote: > > > On 1 March 2017 at 05:42, Alexander Samoylovich <samoylov...@gmail.com > <mailto: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 > <mailto:stepharo.s...@gmail.com>> wrote: > Tx igor I added > > https://pharo.fogbugz.com/f/cases/19764/Improve-comment-of-AthensCairoSurfaceForm > > <https://pharo.fogbugz.com/f/cases/19764/Improve-comment-of-AthensCairoSurfaceForm> > > On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <siguc...@gmail.com > <mailto: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 > <mailto:siguc...@gmail.com>> wrote: > > > On 27 February 2017 at 12:29, Esteban Lorenzano <esteba...@gmail.com > <mailto: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 > > <mailto: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 <mailto: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/ > > <http://www.opera.com/mail/> > > > > > > > > -- > Best regards, > Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko. > > > > > > -- > Best regards, > Igor Stasenko. >
