Crash in Athens
Locked
 
|
Hello 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
<[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/ |
|
|
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
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, |
|
|
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:
 AthensFlyingStick.st (2K) Download Attachment AthensFlyingStickMorph.st (2K) Download Attachment BezierLine.st (2K) Download Attachment |
|
|
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
-- Using Opera's mail client: http://www.opera.com/mail/ |
|
|
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/ |
|
|
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/ > |
|
|
On 27 February 2017 at 12:29, Esteban Lorenzano <[hidden email]> wrote: Hi, 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 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 <[hidden email]> wrote:
Best regards,
Igor Stasenko. |
|
|
On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <[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 On Mon, Feb 27, 2017 at 2:39 PM, Stephane Ducasse <[hidden email]> wrote:
|
|
|
can you add that *in addition* to Ronie’s suggestion? (the one I posted?) Esteban
|
|
|
In reply to this post by Alexander Samoylovich
On 1 March 2017 at 05:42, Alexander Samoylovich <[hidden email]> wrote:
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 :(
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 <[hidden email]> wrote:
|
|
|
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
|
|
|
On 5 March 2017 at 11:03, Esteban Lorenzano <[hidden email]> wrote:
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..
Best regards,
Igor Stasenko. |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |