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.

Dave