On Mon, Jan 06, 2014 at 09:41:12PM +0000, Frank Shearar wrote:
> On 6 January 2014 20:30, David T. Lewis <lewis at mail.msen.com> wrote:
> > 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.
> 
> Yes. And yes, I do see that error when trying to evaluate 'self size'.
> 
> > 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.
> 
> It would be handy if I could tell, but 'self close' also fails in
> #primSize:. (Oh, that's probably because the image tries to log the
> DoIt.)

Any of the file primitives will fail if the file stream does not refer
to a valid open file. Take a look at "SourceFiles last", which is the
changes file. It will have a fileID instance variable that identifies the
file to the VM (it is a byte array representation of a C data structure
that represents the file within the VM plugin, but you are not supposed
to know that ;).

The fileID instance variable of a file stream should look like a byte array,
and "self closed" should answer false for the file stream. If that is
not the case, then you are looking at an file stream on a file that has
been closed, or that is invalid for some other reason.

If you look in your debugger and see a file stream that is failing the
primSize primitive (or any other file system primitive), then it probably
has a fileID that is nil or zeroed out, and that is usually because
the file is closed. I expect that this is what you will find when you
look that the file stream in your debugger. Assuming that this is
the case, then all we need to do is figure out why it's closed.
 
Dave