[squeak-dev] Re: Debugging a primitive failure

Frank Shearar frank.shearar at gmail.com
Mon Jan 6 22:56:39 UTC 2014


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

frank

> Dave
>
>


More information about the Squeak-dev mailing list