7 Jul
2016
7 Jul
'16
9:46 a.m.
Hi,
I am running the latest moose, with VM from May 4th on Linux and I
consistently experience (over a period of several weeks) occasional crashes.
My rough observation is that this happens when working with visualization.
Do I do something wrong, or are there some issues?
The crash dump is attached.
Cheers,
Jan
7 Jul
7 Jul
11:27 a.m.
I consistently experience (over a period of several weeks) occasional
crashes.
If it makes you feel any better, I experience it several times a day…
on Monday it got to a point that I took several days (three and counting)
break from Pharo because I was so utterly frustrated by this…
My rough observation is that this happens when working
with visualization.
Do I do something wrong, or are there some issues?
There are (at least) three different crashes that happen often… two related
to Athens/Roassal it seems (one you reported is one of them) and one
related to fonts.
Of course I reported all of them, but with no known way to reproducibly
crash it, I seriously doubt it will be fixed anytime soon.
1:27 p.m.
I have the same problem and I am also frustrated. But to fix it is very difficult.
Fundamentally, the problem with this issue is to reliably reproduce it. I talked to
Esteban about it, and he needs an image that will reliably crash to be able to debug it.
He has no such image. I have one that almost crashes reliably, and I will give it to him
tomorrow.
If you have an image that always crashes quickly, this is GOLD! Please please please end
it to Esteban so he can debug!
--
Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see
http://emailcharter.org <http://emailcharter.org/> .
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Jul 7, 2016, at 05:27, Peter Uhnák
<i.uhnak(a)gmail.com> wrote:
I consistently experience (over a period of several weeks) occasional crashes.
If it makes you feel any better, I experience it several times a day…
on Monday it got to a point that I took several days (three and counting) break from
Pharo because I was so utterly frustrated by this…
My rough observation is that this happens when working with visualization.
Do I do something wrong, or are there some issues?
There are (at least) three different crashes that happen often… two related to
Athens/Roassal it seems (one you reported is one of them) and one related to fonts.
Of course I reported all of them, but with no known way to reproducibly crash it, I
seriously doubt it will be fixed anytime soon.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
2:02 p.m.
First thing is to upgrade the vm to stable. There have been interesting bug fixes
Stephan
Verstuurd vanaf mijn iPhone
Op 7 jul. 2016 om 13:27 heeft Johan Fabry
<jfabry(a)dcc.uchile.cl> het volgende geschreven:
I have the same problem and I am also frustrated. But to fix it is very difficult.
Fundamentally, the problem with this issue is to reliably reproduce it. I talked to
Esteban about it, and he needs an image that will reliably crash to be able to debug it.
He has no such image. I have one that almost crashes reliably, and I will give it to him
tomorrow.
If you have an image that always crashes quickly, this is GOLD! Please please please end
it to Esteban so he can debug!
--
Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see
http://emailcharter.org .
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
On Jul 7,
2016, at 05:27, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
I consistently experience (over a period of several weeks) occasional crashes.
If it makes you feel any better, I experience it several times a day…
on Monday it got to a point that I took several days (three and counting) break from
Pharo because I was so utterly frustrated by this…
My rough observation is that this happens when working with visualization.
Do I do something wrong, or are there some issues?
There are (at least) three different crashes that happen often… two related to
Athens/Roassal it seems (one you reported is one of them) and one related to fonts.
Of course I reported all of them, but with no known way to reproducibly crash it, I
seriously doubt it will be fixed anytime soon.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 
12:56 p.m.
I am running the latest moose, with VM from May 4th on
Linux and I consistently experience (over a period of several weeks) occasional crashes.
My rough observation is that this happens when working with visualization.
Do I do something wrong, or are there some issues?
The crash dump is attached.
You are not the only one. In your trace:
Smalltalk stack dump:
0xff9f8564 M GrafPort>copyBits 0x95f2390: a(n) GrafPort
0xff9f857c M GrafPort>image:at:sourceRect:rule: 0x95f2390: a(n) GrafPort
0xff9f85a4 M FormCanvas>image:at:sourceRect:rule: 0x95f2428: a(n) FormCanvas
0xff9f85d0 M TRMorph>drawOn: 0x95edd40: a(n) TRMorph
I have no idea what is wrong with the form canvas and this GraphPort.
I have added several guards in TRMorph>>drawOn: they help, but they reduce the user
experience.
It would be help to have that issue fixed. Drawing primitives graphical elements should
not make the crash the VM crash
Alexandre
Cheers,
Jan
<crash.dmp>_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
11:06 p.m.
That dump looks familiar..
----
| surface morph formCanvas |
surface := AthensCairoSurface extent: 100@100.
surface drawDuring: [ :athCan |
athCan
setShape: (0 asPoint corner: 100 asPoint);
setPaint: Color orange;
draw.
].
morph := surface asForm asMorph.
"comment out these two lines, and it draws fine"
surface := nil.
Smalltalk garbageCollect.
formCanvas := FormCanvas extent: 100 asPoint.
morph fullDrawOn: formCanvas .
morph debugDrawError
---
AthensCairoCanvas >>#asForm do not actually return a "valid" form, but an
"external" that holds an index to a Surface, instead of the actual bits, and
somewhere during drawing there is a machinery which finds the surface based
on this index, and copy those bits. That way #asForm do not need to allocate
any bits itself, but at the expense that the lifetime of the surface must be
longer then the form.
I guess you can try to use AthensCairoSurface>>#displayOnMorphicCanvas:at:
in TRMorph>>#drawOn: instead of how it is done now, this should assure that
the Surface is still alive when drawing.
I also think that changing the extent of the surface should be moved from
#layoutChanged to the start of #drawOn:. The layoutChanged/ morph extent
change could happen more than once in between draw calls, which could cause
unnecessary recreations of the surface. It should also ensure that the
surface cannot be recreated while inside #drawOn:.
Hope this helps.
Best regards,
Henrik
--
View this message in context: http://forum.world.st/VM-Crash-tp4905304p4905497.html
Sent from the Moose mailing list archive at Nabble.com.
8 Jul
8 Jul
11:19 a.m.
Hi Henrik,
thank thank you to look into that.
Indeed, that error looks familiar
I guess you can try to use
AthensCairoSurface>>#displayOnMorphicCanvas:at:
in TRMorph>>#drawOn: instead of how it is done now, this should assure that
the Surface is still alive when drawing.
In TRMorph>>drawOn:, replacing
aCanvas image: f at: self bounds origin sourceRect: (0 @ 0 extent: surface extent) rule:
34
by
surface displayOnMorphicCanvas: aCanvas at: 0 @ 0
does not draw anything. Did I do something wrong?
I also think that changing the extent of the surface
should be moved from
#layoutChanged to the start of #drawOn:. The layoutChanged/ morph extent
change could happen more than once in between draw calls, which could cause
unnecessary recreations of the surface. It should also ensure that the
surface cannot be recreated while inside #drawOn:.
Thanks! I have committed this
Running all the Roassal2- tests leaves 5 instances of AthensCairoSurface that cannot be
garbage collected.
With the change you are suggesting, it is reduced to 4. Still something!
Cheers,
Alexandre
Hope this helps.
Best regards,
Henrik
--
View this message in context: http://forum.world.st/VM-Crash-tp4905304p4905497.html
Sent from the Moose mailing list archive at Nabble.com.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
11:24 a.m.
You need to draw it at the correct location in the world ;).
surface displayOnMorphicCanvas: aCanvas at: self position
Best regards,
Henrik
-----Original Message-----
From: moose-dev-bounces(a)list.inf.unibe.ch [mailto:moose-dev-bounces@list.inf.unibe.ch] On
Behalf Of Alexandre Bergel
Sent: Friday, July 8, 2016 11:20 AM
To: Moose-related development <moose-dev(a)list.inf.unibe.ch>
Subject: [Moose-dev] Re: VM Crash?
Hi Henrik,
thank thank you to look into that.
Indeed, that error looks familiar
I guess you can try to use
AthensCairoSurface>>#displayOnMorphicCanvas:at:
in TRMorph>>#drawOn: instead of how it is done now, this should assure
that the Surface is still alive when drawing.
In TRMorph>>drawOn:, replacing
aCanvas image: f at: self bounds origin sourceRect: (0 @ 0 extent: surface extent) rule:
34
by
surface displayOnMorphicCanvas: aCanvas at: 0 @ 0
does not draw anything. Did I do something wrong?
I also think that changing the extent of the surface
should be moved
from #layoutChanged to the start of #drawOn:. The layoutChanged/ morph
extent change could happen more than once in between draw calls,
which could cause unnecessary recreations of the surface. It should
also ensure that the surface cannot be recreated while inside #drawOn:.
Thanks! I have committed this
Running all the Roassal2- tests leaves 5 instances of AthensCairoSurface that cannot be
garbage collected.
With the change you are suggesting, it is reduced to 4. Still something!
Cheers,
Alexandre
Hope this helps.
Best regards,
Henrik
--
View this message in context:
http://forum.world.st/VM-Crash-tp4905304p4905497.html
Sent from the Moose mailing list archive at Nabble.com.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
3:53 p.m.
Okay! It works now.
thanks
Alexandre
On Jul 8, 2016, at 11:24 AM, Henrik Nergaard
<henrik.nergaard(a)uia.no> wrote:
You need to draw it at the correct location in the world ;).
surface displayOnMorphicCanvas: aCanvas at: self position
Best regards,
Henrik
-----Original Message-----
From: moose-dev-bounces(a)list.inf.unibe.ch [mailto:moose-dev-bounces@list.inf.unibe.ch] On
Behalf Of Alexandre Bergel
Sent: Friday, July 8, 2016 11:20 AM
To: Moose-related development <moose-dev(a)list.inf.unibe.ch>
Subject: [Moose-dev] Re: VM Crash?
Hi Henrik,
thank thank you to look into that.
Indeed, that error looks familiar
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I guess you can try to use
AthensCairoSurface>>#displayOnMorphicCanvas:at:
in TRMorph>>#drawOn: instead of how it is done now, this should assure
that the Surface is still alive when drawing.
In TRMorph>>drawOn:, replacing
aCanvas image: f at: self bounds origin sourceRect: (0 @ 0 extent: surface extent) rule:
34
by
surface displayOnMorphicCanvas: aCanvas at: 0 @ 0
does not draw anything. Did I do something wrong?
I also think that changing the extent of the
surface should be moved
from #layoutChanged to the start of #drawOn:. The layoutChanged/ morph
extent change could happen more than once in between draw calls,
which could cause unnecessary recreations of the surface. It should
also ensure that the surface cannot be recreated while inside #drawOn:.
Thanks! I have committed this
Running all the Roassal2- tests leaves 5 instances of AthensCairoSurface that cannot be
garbage collected.
With the change you are suggesting, it is reduced to 4. Still something!
Cheers,
Alexandre
Hope this helps.
Best regards,
Henrik
--
View this message in context:
http://forum.world.st/VM-Crash-tp4905304p4905497.html
Sent from the Moose mailing list archive at Nabble.com.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
7 Jul
7 Jul
6:43 p.m.
One way to investigate where the problem comes from, is to understand what keeps some
references of AthensCairoSurface
These objects contains some external resources, and my images are full of them. No idea
why they are kept along. I will investigate this soon, but if you want to give a try,
please do.
Alexandre
On Jul 7, 2016, at 9:46 AM, Jan Kurš
<kurs.jan(a)gmail.com> wrote:
Hi,
I am running the latest moose, with VM from May 4th on Linux and I consistently
experience (over a period of several weeks) occasional crashes.
My rough observation is that this happens when working with visualization.
Do I do something wrong, or are there some issues?
The crash dump is attached.
Cheers,
Jan
<crash.dmp>_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
8:18 p.m.
Put an image on dropbox so Esteban can look at it as well!!
--
Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see
http://emailcharter.org .
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Jul 7, 2016, at 12:43, Alexandre Bergel
<alexandre.bergel(a)me.com> wrote:
One way to investigate where the problem comes from, is to understand what keeps some
references of AthensCairoSurface
These objects contains some external resources, and my images are full of them. No idea
why they are kept along. I will investigate this soon, but if you want to give a try,
please do.
Alexandre
On Jul 7, 2016, at 9:46 AM, Jan Kurš
<kurs.jan(a)gmail.com> wrote:
Hi,
I am running the latest moose, with VM from May 4th on Linux and I consistently
experience (over a period of several weeks) occasional crashes.
My rough observation is that this happens when working with visualization.
Do I do something wrong, or are there some issues?
The crash dump is attached.
Cheers,
Jan
<crash.dmp>_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
3088
days inactive
3089
days old
10 comments
6 participants
participants (6)
-
Alexandre Bergel -
Henrik Nergaard -
Jan Kurš -
Johan Fabry -
Peter Uhnák -
Stephan Eggermont