On Tue, Mar 13, 2012 at 7:44 AM, Tudor Girba tudor@tudorgirba.com wrote:
Strange. I tried to reproduce the problem, but following the same path worked fine the second time.
Such GC bugs are extremely sensitive to exactly the sequence of mutations in the heap. So the time in between mouse clicks or keyboard presses, or even the length of delays or the date and time can change the form of the heap. The only way I know to reproduce this kind of bug reliably is to write a doit that causes the system to crash without user intervention. You can either supply the doit in a file to the VM at startup or (more convenient for those debugging it) write a doit that starts with a snapshot, e.g.
Smalltalk saveAs. Crasher new crash
Doru
On Tue, Mar 13, 2012 at 3:18 PM, Tudor Girba tudor@tudorgirba.com wrote:
Ah, I forgot to mention: the same scenario works with the VM from Eliot
(2522)
Cheers, Doru
On Tue, Mar 13, 2012 at 3:16 PM, Tudor Girba tudor@tudorgirba.com
wrote:
Hi,
I just tried it and it crashed :(.
Here is what I did:
- I took the Moose image
- it started fine, and seem to be responsive
- I then loaded code in it using a configuration
- while loading, it crashed
I attach here the crash.dmp file. I cannot provide the actual code because it is proprietary. I will try to reproduce the problem in more available settings.
Cheers, Doru
On Tue, Mar 13, 2012 at 8:54 AM, Torsten Bergmann astares@gmx.de
wrote:
Thanks Igor. Guys can you try and report if you have problems?
Yes, thanks Igor,
How can I see if this release integrates Eliots latest fixes for Cog?
Thx T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
On 15 March 2012 19:28, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Mar 13, 2012 at 7:44 AM, Tudor Girba tudor@tudorgirba.com wrote:
Strange. I tried to reproduce the problem, but following the same path worked fine the second time.
Such GC bugs are extremely sensitive to exactly the sequence of mutations in the heap. So the time in between mouse clicks or keyboard presses, or even the length of delays or the date and time can change the form of the heap. The only way I know to reproduce this kind of bug reliably is to write a doit that causes the system to crash without user intervention. You can either supply the doit in a file to the VM at startup or (more convenient for those debugging it) write a doit that starts with a snapshot, e.g.
Smalltalk saveAs. Crasher new crash
Not again this flaky GC/become stuff. I was hoping that last one we busted in summer..
Hi,
The problem is that I cannot get it for you because it's proprietary code, and the issue raised when loading the code from a Monticello repository.
I got some strange crashes in other contexts but without having time to dig into these :(. I will try to keep my eyes opened and find some reproducible case.
Cheers, Doru
On 15 Mar 2012, at 20:03, Igor Stasenko wrote:
On 15 March 2012 19:28, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Mar 13, 2012 at 7:44 AM, Tudor Girba tudor@tudorgirba.com wrote:
Strange. I tried to reproduce the problem, but following the same path worked fine the second time.
Such GC bugs are extremely sensitive to exactly the sequence of mutations in the heap. So the time in between mouse clicks or keyboard presses, or even the length of delays or the date and time can change the form of the heap. The only way I know to reproduce this kind of bug reliably is to write a doit that causes the system to crash without user intervention. You can either supply the doit in a file to the VM at startup or (more convenient for those debugging it) write a doit that starts with a snapshot, e.g.
Smalltalk saveAs. Crasher new crashNot again this flaky GC/become stuff. I was hoping that last one we busted in summer..
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com
"No matter how many recipes we know, we still value a chef."
Hi Tudor,
On Thu, Mar 15, 2012 at 2:55 PM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
The problem is that I cannot get it for you because it's proprietary code, and the issue raised when loading the code from a Monticello repository.
I sign non-disclosure agreements and destroy files once I'm done :) So if you can get it to crash loading from a package-cache and you're happy for me to sign an NDA I can still look at it. But only if you;re comfortable and only if you have a reproducible case.
I got some strange crashes in other contexts but without having time to dig into these :(. I will try to keep my eyes opened and find some reproducible case.
Cheers, Doru
cool.
cheers!
On 15 Mar 2012, at 20:03, Igor Stasenko wrote:
On 15 March 2012 19:28, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Mar 13, 2012 at 7:44 AM, Tudor Girba tudor@tudorgirba.com
wrote:
Strange. I tried to reproduce the problem, but following the same path worked fine the second time.
Such GC bugs are extremely sensitive to exactly the sequence of
mutations in the heap. So the time in between mouse clicks or keyboard presses, or even the length of delays or the date and time can change the form of the heap. The only way I know to reproduce this kind of bug reliably is to write a doit that causes the system to crash without user intervention. You can either supply the doit in a file to the VM at startup or (more convenient for those debugging it) write a doit that starts with a snapshot, e.g.
Smalltalk saveAs. Crasher new crashNot again this flaky GC/become stuff. I was hoping that last one we busted in summer..
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com
"No matter how many recipes we know, we still value a chef."
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Igor Stasenko -
Tudor Girba