On 28 August 2013 12:19, David T. Lewis <lewis at mail.msen.com> 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!

frank

> Dave
>
>