On 28 August 2013 15:28, Frank Shearar frank.shearar@gmail.com wrote:
On 28 August 2013 12:19, David T. Lewis lewis@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/...
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