On Mon, Jan 06, 2014 at 05:51:24PM +0000, Frank Shearar wrote:
> On 6 January 2014 14:23, David T. Lewis <lewis at mail.msen.com> wrote:
> > On Mon, Jan 06, 2014 at 01:48:17PM +0000, Frank Shearar wrote:
> >> On 6 January 2014 11:40, Frank Shearar <frank.shearar at gmail.com> wrote:
> >> > At any rate, I've managed to do this three times in a row. Something's
> >> > not right somewhere. How might I start trying to debug this?
> >> >
> >> > I would try save the image and offer it up for inspection, but of
> >> > course I can't do that because that involves the changes file. I can't
> >> > even file out a changeset, class or method. I'm going to try redo the
> >> > changes I made, and prep a changeset. To be clear: I only see the
> >> > failure when I run the test, and that somehow breaks the changes file.
> >>
> >> In a COPY of your latest trunk image, run the attached changeset. Open
> >> up a TestRunner. Run the MCPackageTest. Try debug the failure. You
> >> should see a debugger pop up complaining that primSize failed on your
> >> changes file. At least, that's what happens locally. After this, your
> >> changes file is corrupt, in that nothing touching the changes file
> >> works anymore (primSize failures).
> >>
> >
> > I am not seeing the failure. What is the actual size of your changes
> > file at the time that the problem occurs?
> 
> 11866903 bytes. Maybe I should get another image from some independent source.
> 

I don't know what's happening, but take a look in the debugger when it
happens. It will be failing on StandardFileStream>>size and the only reason
I can think that this would occur is if the file stream was closed. The
changes file gets opened and closed a lot, so maybe you're seeing some
kind of concurrency issue.

Dave