On 6 January 2014 22:56, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 6 January 2014 22:26, David T. Lewis <lewis at mail.msen.com> wrote:
>> 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.
>
> Yep, the fileID's zeroed out. So all we need to figure out is who closed it :)

So am I the only guy getting hit by this? I'll be working in an image,
not doing anything much, and suddenly I can't save any changes: saving
a method, do-it, etc. all throw up debuggers because the FileStream's
closed. (I'm running Windows 8 64bit - any other such users out
there?)

frank

> frank
>
>> Dave
>>
>>