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
On Wed, Feb 22, 2017 at 11:55 AM, Alexander Samoylovich <samoylovich@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
The *ideal* thing to troubleshoot VM crashes is a test case that is reproducible without human intervention. You save the image so that your test case executes immediately upon image startup. For example, by evaluating these two lines together... Smalltalk snapshot: true andQuit: true. 1 inform: 'MY TEST CASE RUN AT IMAGE STARTUP'. This doesn't need to be done in a fresh image, but thats slightly better. If you can't make your test case that tight, more general steps to reproduce are also welcome. Just keep in mind the easier it is to reproduce, the easier it is for others to work on it, and for us to reduce bug bankruptcy [1]. For tracking, log an issue at https://pharo.fogbugz.com/ Please report any difficulty you have signing up and doing this. Mileage may very, but also try updating to latest VM... http://files.pharo.org/vm/pharo-spur32/mac/ Report Image and VM versions from World > System > System Reporter. cheers -ben [1] https://www.joelonsoftware.com/2012/07/09/software-inventory/
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 <samoylovich@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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hello, http://forum.world.st/Too-frequent-crashes-td4927143i20.html#a4934027 Try changing AthensCairoSurface >> asForm into the following method: 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 seems to improve the stability a lot. I have already told Esteban to take a better look. Best regards, Ronie 2017-02-22 13:47 GMT-03:00 Alexandre Bergel <alexandre.bergel@me.com>:
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 < samoylovich@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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 <samoylovich@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/
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? Esteban
On 24 Feb 2017, at 15:47, stepharong <stepharong@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 <samoylovich@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/
On 27 February 2017 at 12:29, Esteban Lorenzano <estebanlm@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 <stepharong@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 < samoylovich@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.
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 <siguctua@gmail.com> wrote:
On 27 February 2017 at 12:29, Esteban Lorenzano <estebanlm@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 <stepharong@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 < samoylovich@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.
Tx igor I added https://pharo.fogbugz.com/f/cases/19764/Improve-comment-of-AthensCairoSurfac... On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <siguctua@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 <siguctua@gmail.com> wrote:
On 27 February 2017 at 12:29, Esteban Lorenzano <estebanlm@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 <stepharong@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 < samoylovich@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.
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 On Mon, Feb 27, 2017 at 2:39 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Tx igor I added
https://pharo.fogbugz.com/f/cases/19764/Improve-comment- of-AthensCairoSurfaceForm
On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <siguctua@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 <siguctua@gmail.com> wrote:
On 27 February 2017 at 12:29, Esteban Lorenzano <estebanlm@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 <stepharong@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 < samoylovich@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.
On 1 Mar 2017, at 04:42, Alexander Samoylovich <samoylovich@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
can you add that *in addition* to Ronieâs suggestion? (the one I posted?) Esteban
On Mon, Feb 27, 2017 at 2:39 PM, Stephane Ducasse <stepharo.self@gmail.com <mailto:stepharo.self@gmail.com>> wrote: Tx igor I added
https://pharo.fogbugz.com/f/cases/19764/Improve-comment-of-AthensCairoSurfac... <https://pharo.fogbugz.com/f/cases/19764/Improve-comment-of-AthensCairoSurfac...>
On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <siguctua@gmail.com <mailto:siguctua@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 <siguctua@gmail.com <mailto:siguctua@gmail.com>> wrote:
On 27 February 2017 at 12:29, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@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 <stepharong@free.fr <mailto:stepharong@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 <samoylovich@gmail.com <mailto:samoylovich@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.
On 1 March 2017 at 05:42, Alexander Samoylovich <samoylovich@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.self@gmail.com
wrote:
Tx igor I added
https://pharo.fogbugz.com/f/cases/19764/Improve-comment-of- AthensCairoSurfaceForm
On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <siguctua@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 <siguctua@gmail.com> wrote:
On 27 February 2017 at 12:29, Esteban Lorenzano <estebanlm@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 <stepharong@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 < samoylovich@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.
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 <siguctua@gmail.com> wrote:
On 1 March 2017 at 05:42, Alexander Samoylovich <samoylovich@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.self@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 <siguctua@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 <siguctua@gmail.com> wrote:
On 27 February 2017 at 12:29, Esteban Lorenzano <estebanlm@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 <stepharong@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 < samoylovich@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.
On 5 Mar 2017, at 05:00, Alexander Samoylovich <samoylovich@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 <siguctua@gmail.com <mailto:siguctua@gmail.com>> wrote:
On 1 March 2017 at 05:42, Alexander Samoylovich <samoylovich@gmail.com <mailto:samoylovich@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.self@gmail.com <mailto:stepharo.self@gmail.com>> wrote: Tx igor I added
https://pharo.fogbugz.com/f/cases/19764/Improve-comment-of-AthensCairoSurfac... <https://pharo.fogbugz.com/f/cases/19764/Improve-comment-of-AthensCairoSurfac...>
On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <siguctua@gmail.com <mailto:siguctua@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 <siguctua@gmail.com <mailto:siguctua@gmail.com>> wrote:
On 27 February 2017 at 12:29, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@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 <stepharong@free.fr <mailto:stepharong@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 <samoylovich@gmail.com <mailto:samoylovich@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.
On 5 March 2017 at 11:03, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 5 Mar 2017, at 05:00, Alexander Samoylovich <samoylovich@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).
Well, this surely helps when you changing session(s). But doesn't helps
when you crashing within a single session. A smarter approach will be to recreate surface at attempt to use in new session, to avoid keeping copy of data around..
Esteban
-- Best regards, Igor Stasenko.
participants (8)
-
Alexander Samoylovich -
Alexandre Bergel -
Ben Coman -
Esteban Lorenzano -
Igor Stasenko -
Ronie Salgado -
Stephane Ducasse -
stepharong