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

I'm not doing any heavy concurrency stuff though: I'm just running a
little test, that shouldn't involve Processes at all.

frank

> Dave