[squeak-dev] Re: Debugging a primitive failure

Chris Muller asqueaker at gmail.com
Sat Jan 11 22:32:23 UTC 2014


Is it possible another copy of the image launched?  Two images trying
to use the same .changes file?

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
>>>
>>>
>


More information about the Squeak-dev mailing list