Hi Tudor, On Thu, Mar 15, 2012 at 2:55 PM, Tudor Girba <[email protected]> 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 <[email protected]> wrote: > >> > >> > >> > >> On Tue, Mar 13, 2012 at 7:44 AM, Tudor Girba <[email protected]> > 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.. > > > > > > -- > > Best regards, > > Igor Stasenko. > > -- > www.tudorgirba.com > > "No matter how many recipes we know, we still value a chef." > > > > > > > -- best, Eliot
