pharo 4.0 Crashed in the VM thread again

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

Re: pharo 4.0 Crashed in the VM thread again

Sabine Manaa
Hi,

with the help of Eliot, I was able to reduce the problem and created a fileout, it is only one class with one method. The fileout reproduces the crash. Take a new Pharo 4 image, file in the attached .st and do the steps described in the comment.

Eliot told me that it is possibly a compiler bug and asked me to send this to Marcus or Esteban. Here it is.

_Note_, that the method does not make sense because I removed all my stuff for creating an easy reproducible case. The crash dump looks similar to the dumps in my case, so I hope it is the same.

Eliots words are that " that the method should have the large context flag set but that it doesn't"

The key point is, as far as I understand, that the method is (too) long. My method also was long (it gathered much stuff for a big report.). After refactoring, it disapeared. 

The punishment for writing a long method was hard, because it took a lot of time to find the reason for the crashes ;-)))

Have a nice sunday
Sabine

2015-07-22 22:49 GMT+02:00 Eliot Miranda-2 [via Smalltalk] <[hidden email]>:
 
Hi Sabine,

On Tue, Jul 21, 2015 at 12:27 AM, Sabine Manaa <[hidden email]> wrote:
 
Eliot,
is Cog.app-15.28.3410.tgz the right one?

That's Mac OS X.  You'll want cogwin-15.28.3410.zip

 
Regards
Sabine

2015-07-21 9:24 GMT+02:00 Sabine Manaa <[hidden email]>:
This is production: Windows Server 2008 R2 Datacenter

Development is MacOs

2015-07-20 23:04 GMT+02:00 Stephan Eggermont [via Smalltalk] <[hidden email]>:
 


On 20/07/15 22:55, Eliot Miranda wrote:
>
> Are you on Mac OS X or Linux?

Windows Server 2008 R2 Datacenter says the first mail in this thread

Stephan



If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/pharo-4-0-Crashed-in-the-VM-thread-again-tp4836826p4838441.html
To unsubscribe from pharo 4.0 Crashed in the VM thread again, click here.
NAML




View this message in context: Re: pharo 4.0 Crashed in the VM thread again
Sent from the Squeak VM mailing list archive at Nabble.com.




--
_,,,^..^,,,_
best, Eliot



If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/pharo-4-0-Crashed-in-the-VM-thread-again-tp4836826p4838728.html
To unsubscribe from pharo 4.0 Crashed in the VM thread again, click here.
NAML


RKADemoCrash.st (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pharo 4.0 Crashed in the VM thread again

timrowledge

Sabine,
As a general rule of thumb, if a method is too long to see at a glance - in practice this means too long to fit on your screen - then it almost certainly needs splitting up. I have been forcibly reminded of this a lot recently due to having to decode insanely long Python routines; seriously - 1100 lines for a single function?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: FSRA: Forms Skip and Run-Away


Reply | Threaded
Open this post in threaded view
|

Re: pharo 4.0 Crashed in the VM thread again

Nicolai Hess
 
Pharo or Squeak ?

In squeak, this stackframe / large stackframe bug was introduced some months ago by a change for the compiler but it is already fixed.
In pharo, we have a simliar bug (in pharos compiler (opal), not related to the change on the squeak compiler).
This is a bug that is known but not yet fixed
frameSize calculated wrongly for #lineSegmentsDo: !



2015-08-09 18:39 GMT+02:00 tim Rowledge <[hidden email]>:

Sabine,
As a general rule of thumb, if a method is too long to see at a glance - in practice this means too long to fit on your screen - then it almost certainly needs splitting up. I have been forcibly reminded of this a lot recently due to having to decode insanely long Python routines; seriously - 1100 lines for a single function?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: FSRA: Forms Skip and Run-Away



Reply | Threaded
Open this post in threaded view
|

Re: pharo 4.0 Crashed in the VM thread again

Sabine Manaa
It is in a new pharo 4 image and yes, I know about method size. This was my own lazyness within a method gathering data for a report...as I was saying, punishment was hard.

2015-08-09 18:56 GMT+02:00 Nicolai Hess [via Smalltalk] <[hidden email]>:
 
Pharo or Squeak ?

In squeak, this stackframe / large stackframe bug was introduced some months ago by a change for the compiler but it is already fixed.
In pharo, we have a simliar bug (in pharos compiler (opal), not related to the change on the squeak compiler).
This is a bug that is known but not yet fixed
frameSize calculated wrongly for #lineSegmentsDo: !



2015-08-09 18:39 GMT+02:00 tim Rowledge <[hidden email]>:

Sabine,
As a general rule of thumb, if a method is too long to see at a glance - in practice this means too long to fit on your screen - then it almost certainly needs splitting up. I have been forcibly reminded of this a lot recently due to having to decode insanely long Python routines; seriously - 1100 lines for a single function?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: FSRA: Forms Skip and Run-Away






If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/pharo-4-0-Crashed-in-the-VM-thread-again-tp4836826p4841830.html
To unsubscribe from pharo 4.0 Crashed in the VM thread again, click here.
NAML

12