Crash in Athens

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Crash in Athens

Alexander Samoylovich
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
Reply | Threaded
Open this post in threaded view
|

Re: Crash in Athens

Ben Coman
On Wed, Feb 22, 2017 at 11:55 AM, Alexander Samoylovich
<[hidden email]> 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/

Reply | Threaded
Open this post in threaded view
|

Re: Crash in Athens

abergel
In reply to this post by Alexander Samoylovich
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 <[hidden email]> 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




Reply | Threaded
Open this post in threaded view
|

Re: Crash in Athens

Ronie Salgado
Hello,
 

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 <[hidden email]>:
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 <[hidden email]> 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.





Reply | Threaded
Open this post in threaded view
|

Re: Crash in Athens

Alexander Samoylovich
In reply to this post by Alexander Samoylovich
Hello.

I can reproduce the bug "semi-automatically". The tree classes I use to crash are attached.
Run

AthensFlyingStickMorph new openInWorld

and wait. Sometimes it crashes immediately. Sometimes I have to wait a couple of minutes.
If I done not resize the crash never or almost never happens.

Thank you,
Alex 

On Wed, Feb 22, 2017 at 11:56 AM, Ronie Salgado <[hidden email]> wrote:
Hello,
 

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 <[hidden email]>:
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 <[hidden email]> 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.







AthensFlyingStick.st (2K) Download Attachment
AthensFlyingStickMorph.st (2K) Download Attachment
BezierLine.st (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Crash in Athens

stepharong
Hi alexander

Thanks for reporting to us your findings. 
Can you report on which 
   - os
   - version os 
   - which pharo vm (there is a system report option) 
   - which image 

Stef


Hello.

I can reproduce the bug "semi-automatically". The tree classes I use to crash are attached.
Run

AthensFlyingStickMorph new openInWorld

and wait. Sometimes it crashes immediately. Sometimes I have to wait a couple of minutes.
If I done not resize the crash never or almost never happens.

Thank you,
Alex 

On Wed, Feb 22, 2017 at 11:56 AM, Ronie Salgado <[hidden email]> wrote:
Hello,
 

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 <[hidden email]>:
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 <[hidden email]> 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.









--
Using Opera's mail client: http://www.opera.com/mail/
Reply | Threaded
Open this post in threaded view
|

Re: Crash in Athens

stepharong
In reply to this post by abergel
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  
>> <[hidden email]> 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/

Reply | Threaded
Open this post in threaded view
|

Re: Crash in Athens

EstebanLM
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 <[hidden email]> 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 <[hidden email]> 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/
>


Reply | Threaded
Open this post in threaded view
|

Re: Crash in Athens

Igor Stasenko


On 27 February 2017 at 12:29, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Crash in Athens

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 <[hidden email]> wrote:


On 27 February 2017 at 12:29, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Crash in Athens

Stephane Ducasse-3

On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <[hidden email]> 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 <[hidden email]> wrote:


On 27 February 2017 at 12:29, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Crash in Athens

Alexander Samoylovich
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 <[hidden email]> wrote:

On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <[hidden email]> 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 <[hidden email]> wrote:


On 27 February 2017 at 12:29, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: Crash in Athens

EstebanLM

On 1 Mar 2017, at 04:42, Alexander Samoylovich <[hidden email]> 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 <[hidden email]> wrote:

On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <[hidden email]> 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 <[hidden email]> wrote:


On 27 February 2017 at 12:29, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

Re: Crash in Athens

Igor Stasenko
In reply to this post by Alexander Samoylovich


On 1 March 2017 at 05:42, Alexander Samoylovich <[hidden email]> 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 <[hidden email]> wrote:

On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <[hidden email]> 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 <[hidden email]> wrote:


On 27 February 2017 at 12:29, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Crash in Athens

Alexander Samoylovich
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 <[hidden email]> wrote:


On 1 March 2017 at 05:42, Alexander Samoylovich <[hidden email]> 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 <[hidden email]> wrote:

On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <[hidden email]> 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 <[hidden email]> wrote:


On 27 February 2017 at 12:29, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Crash in Athens

EstebanLM

On 5 Mar 2017, at 05:00, Alexander Samoylovich <[hidden email]> 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 <[hidden email]> wrote:


On 1 March 2017 at 05:42, Alexander Samoylovich <[hidden email]> 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 <[hidden email]> wrote:

On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <[hidden email]> 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 <[hidden email]> wrote:


On 27 February 2017 at 12:29, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: Crash in Athens

Igor Stasenko


On 5 March 2017 at 11:03, Esteban Lorenzano <[hidden email]> wrote:

On 5 Mar 2017, at 05:00, Alexander Samoylovich <[hidden email]> 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.