David T. Lewis wrote:
It looks like ObjectMemory>>pushRemappableOop: is using a stack which
has been allocated with > 25 elements, and it has no error checking to prevent stack overflows.
p.s. Just comment out the call to primitiveGetEnvironmentStrings in WindowsOSProcessAccessor>>primGetEnvironmentStrings if you want to get OSProcess working. There will probably be some things that don't
work right in
CommandShell if you do this, but at least your VM should stop crashing
;)
Instead, I pumped up the 'remapBuffer[26]' to 'remapBuffer[128]' then everything worked like a charm.
Maybe someone should revise the VM to ensure that there will be no overflows.
My only concern was that how were the numbers arrived at for things like:
int atCache[65]; int (*compilerHooks[16])(); int externalPrimitiveTable[4097]; int methodCache[4097]; int remapBuffer[26]; int rootTable[2501]; int semaphoresToSignalA[501]; int semaphoresToSignalB[501];
Cheers,
PhiHo.
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of David T. Lewis Sent: Saturday, March 16, 2002 8:30 AM To: squeak-dev@lists.squeakfoundation.org Subject: Re: [ENH][GOODIE] OSProcess V3.0 (OSProcess for Windows)
On Fri, Mar 15, 2002 at 03:51:43AM -0500, PhiHo Hoang wrote:
David,
You may want to look into 'primitiveGetEnvironmentStrings' which
calls 'stringFromCString(p)' and crashed the GC system.
The call stack shows 'stringFromCString', 'instantiateClassindexableSize', 'sufficientSpaceAfterGC', 'incrementalGC', 'fullGC'. The problem is in this loop:
Very interesting. How large is the environment on your Windows (Win2k?) system? Are there more that 25 environment variables defined?
Here is what I think is happening:
Win32OSProcessPlugin>>primitiveGetEnvironmentStrings reads your environment block. For each entry, it creates a Smalltalk String and pushes it onto a special stack of "non-remappable" objects with ObjectMemory>>pushRemappableOop:.
It looks like ObjectMemory>>pushRemappableOop: is using a stack which has been allocated with 25 elements, and it has no error checking to prevent stack overflows.
My guess is that you have more than 25 strings in your environment, and that my code is stepping past the end of the stack and blowing up the VM as a result.
The problem would not show up on my Win98 computer because I have only a few environment variables defined. It does not show up on Unix systems because I used a different method of getting the environment in UnixOSProcessPlugin.
I'll put out some patches if a day or so. Thanks again for the debugging help.
Dave
p.s. Just comment out the call to primitiveGetEnvironmentStrings in WindowsOSProcessAccessor>>primGetEnvironmentStrings if you want to get OSProcess working. There will probably be some things that don't work right in CommandShell if you do this, but at least your VM should stop crashing ;)