On Mon, Jan 06, 2014 at 06:43:50PM +0000, Frank Shearar wrote:
> On 6 January 2014 18:06, David T. Lewis <lewis at mail.msen.com> wrote:
> > 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.
> 
> MultiByteFileStream >> #size is quite high on the stack trace, but I
> imagine that's the same deal.
>

I'm trying to suggest that you inspect the file stream itself in the
debugger. I expect that this will be a MultiByteFileStream on the changes
file, and that if you do a "self size" on that file stream, you will see
the error in primSize.

Each time something is written to the changes file we do a StandardFileStream>>setToEnd
to position the file point to the end of the file prior to doing the write.
That's probably where the failure is happening, and the likely cause would
be that the file stream is closed for some reason.

Dave