[squeak-dev] Can't update past Tests-cmm.249

Frank Shearar frank.shearar at gmail.com
Sat Sep 14 19:27:36 UTC 2013


On 28 August 2013 15:28, Frank Shearar <frank.shearar at gmail.com> wrote:
> 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!

Also, I only just remembered that Windows is Special(tm) about
stdout/stderr, which is why Eliot has so kindly provided Squeak.exe
and SqueakConsole.exe. If you want to use Squeak in a scripty-unixy
type way on a Windows machine, SqueakConsole.exe is what you want to
use!

frank

> frank
>
>> Dave
>>
>>


More information about the Squeak-dev mailing list