On 11 January 2014 22:32, Chris Muller <asqueaker at gmail.com> wrote:
> Is it possible another copy of the image launched?  Two images trying
> to use the same .changes file?

Not in this case, no. Just one image open, mucking around. It happens
constantly when hacking on Monticello-into-Environment hacking, but
this last time I was just tooling around, when the debugger popped up.

frank

> On Fri, Jan 10, 2014 at 4:50 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>> 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
>>>>
>>>>
>>
>