Can't update past Tests-cmm.249

> I have a Squeak4.5 from the squeak-ci repository, on Windows (Squeak
> 4.20.1-2612 interpreter VM). I run the update-image.st script, and I
> can't update past Tests-cmm249. The symptom is a process burning a
> hole in my CPU, and a host of "WARNING: Manufactured file handle
> detected!". The last warning is truncated though - "WARNING:
> Manufactured f", which heightens my suspicion that something has gone
> badly wrong, possibly at the VM level?
>
> Any thoughts?
>
> frank

> On Wed, Aug 28, 2013 at 11:39:39AM +0100, Frank Shearar wrote:
>> I have a Squeak4.5 from the squeak-ci repository, on Windows (Squeak
>> 4.20.1-2612 interpreter VM). I run the update-image.st script, and I
>> can't update past Tests-cmm249. The symptom is a process burning a
>> hole in my CPU, and a host of "WARNING: Manufactured file handle
>> detected!". The last warning is truncated though - "WARNING:
>> Manufactured f", which heightens my suspicion that something has gone
>> badly wrong, possibly at the VM level?
>>
>> Any thoughts?
>>
>> frank
>
> The message originates from this (see line 325):
>
> http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c?revision=2521&view=markup
>
> Explanation:
>
> The Windows VM has a feature (or mis-feature depending on your point of
> view) that tests file references passed to file primitives to ensure
> that they were created by the file plugin itself, and not by something
> else. By "file reference" I mean the fileID instance variable of a file
> stream.
>
> On other platforms, this check does not exist, and the "manufactured"
> file handle will be processed in the primitive (where, if it is invalid,
> it will fail at the point of some actual operating system call).
>
> If you are seeing this error message, it means that a file plugin
> operation is failing when attempting to operate on a file handle that
> was not registered in the windows file plugin during the current session.
> The invalid file handle might be a left-over reference from some prior
> session that was not cleaned up after image restart, or it might be an
> actual corrupt file reference, or it might be a file handle that was
> created outside of the file plugin (e.g. by OSProcessPlugin) and that
> was therefore not registered in the file plugin as a legitimate file
> handle.
>
> Andreas added this check as a general security precaution, although the
> original motivation was prompted by file handles for OS pipe streams
> generated by OSProcessPlugin, which I was passing to the file plugin
> to be handled in the same manner as files. If you have OSProcess in
> your image, and if it previously was running on unix/linux/os x, the
> perhaps there are left over pipe references causing a problem for
> some reason (but that is pure speculation on my part).
>
> Most likely there is something wrong in some error handling code in
> the image during the update process that is somehow aggrivated by
> the handling in the Windows VM. I really don't know what that might
> be, but maybe this will give you some ideas.

> On 28 August 2013 12:19, David T. Lewis <[hidden email]> wrote:
>> On Wed, Aug 28, 2013 at 11:39:39AM +0100, Frank Shearar wrote:
>>> I have a Squeak4.5 from the squeak-ci repository, on Windows (Squeak
>>> 4.20.1-2612 interpreter VM). I run the update-image.st script, and I
>>> can't update past Tests-cmm249. The symptom is a process burning a
>>> hole in my CPU, and a host of "WARNING: Manufactured file handle
>>> detected!". The last warning is truncated though - "WARNING:
>>> Manufactured f", which heightens my suspicion that something has gone
>>> badly wrong, possibly at the VM level?
>>>
>>> Any thoughts?
>>>
>>> frank
>>
>> The message originates from this (see line 325):
>>
>> http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c?revision=2521&view=markup
>>
>> Explanation:
>>
>> The Windows VM has a feature (or mis-feature depending on your point of
>> view) that tests file references passed to file primitives to ensure
>> that they were created by the file plugin itself, and not by something
>> else. By "file reference" I mean the fileID instance variable of a file
>> stream.
>>
>> On other platforms, this check does not exist, and the "manufactured"
>> file handle will be processed in the primitive (where, if it is invalid,
>> it will fail at the point of some actual operating system call).
>>
>> If you are seeing this error message, it means that a file plugin
>> operation is failing when attempting to operate on a file handle that
>> was not registered in the windows file plugin during the current session.
>> The invalid file handle might be a left-over reference from some prior
>> session that was not cleaned up after image restart, or it might be an
>> actual corrupt file reference, or it might be a file handle that was
>> created outside of the file plugin (e.g. by OSProcessPlugin) and that
>> was therefore not registered in the file plugin as a legitimate file
>> handle.
>>
>> Andreas added this check as a general security precaution, although the
>> original motivation was prompted by file handles for OS pipe streams
>> generated by OSProcessPlugin, which I was passing to the file plugin
>> to be handled in the same manner as files. If you have OSProcess in
>> your image, and if it previously was running on unix/linux/os x, the
>> perhaps there are left over pipe references causing a problem for
>> some reason (but that is pure speculation on my part).
>>
>> Most likely there is something wrong in some error handling code in
>> the image during the update process that is somehow aggrivated by
>> the handling in the Windows VM. I really don't know what that might
>> be, but maybe this will give you some ideas.
>
> So the Tests-cmm.249 thing was a red herring. It was simply the latest
> commit. The problem was that the update script called #close where it
> should have called #flush. Since stderr was then closed, reporting an
> error writing to it caused an error, which lead to an infinite
> regress.
>
> Fun times!