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.

frank

> Dave
>
>