Smalltalk › Pharo › Pharo Smalltalk Developers

Too frequent crashes :-(

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

25 messages Options

Ronie Salgado

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

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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>> So what was your crash problem?
>>
>>
>> On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel <[hidden email]> 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 <[hidden email]> wrote:
>>> Okay, trying…
>>>
>>> Alexandre
>>>
>>>
>>>> On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel <[hidden email]> 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 <[hidden email]> 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
>>>> [hidden email]
>>>> 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 (520 bytes) Download Attachment

AthensCairoSurfaceForm.st (2K) Download Attachment

philippeback

Re: [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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>> So what was your crash problem?
>>
>>
>> On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel <[hidden email]> 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 <[hidden email]> wrote:
>>> Okay, trying…
>>>
>>> Alexandre
>>>
>>>
>>>> On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel <[hidden email]> 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 <[hidden email]> 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
>>>> [hidden email]
>>>> 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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>

abergel

Re: [Moose-dev] Too frequent crashes :-(

In reply to this post by Ronie Salgado

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.

Ronie Salgado

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

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.

Eliot Miranda-2

Re: [Moose-dev] Too frequent crashes :-(

Hi Ronie,

On Tue, Mar 14, 2017 at 5:08 PM, Ronie Salgado <[hidden email]> 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 <[hidden email]>:
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