Despite: "Maturity level/Rock solid - Useable and hasn't had bugs for a
long time." The following occurs reproducibly on a bog-standard winXPSP2 box: * Install Squeak3.9-final-7067 * Install squeak-dev-72-2 * Launch squeak-dev-72-2.image * World menu -> old desktop menu -> open ... -> SqueakMap Package Loader * Select 15-Puzzle (-> 1.1) * Menu -> first two items are "install" and "email package maintainers" * Latter produces the "gaelli@" email address I'm copying this to * Former produces "error occurred during install". Puzzle appears anyway * Scramble and unscramble puzzle works normally * World menu -> old desktop menu -> previous project returns to main world * There a debugger can be seen. Bug report below. Upshot: seems a Player56 instance's scripts ivar is ending up an integer instead of an IdentityDictionary. * Open a system browser and find some method. Pick senders of. Pick a method. Witness "primitive failed" debugger. * Cause is a corrupt CompiledMethod object; senders grovels over all compiled methods in the system. This particular CompiledMethod object is for Player57's setEmptyCell: method. * Yes -- that would be *your* Player57 class, Gaelli. :) * To recover normal behavior, unloading the "1415 Puzzle" world seems called-for. X the window and get another attempt to invoke an IdentityDictionary method on a SmallInteger. * Do a little digging and discover that Player56 can have its "scripts" ivar reset with jettisonScripts * Open an inspector on the Player56 instance causing all the trouble and eval "self jettisonScripts" * The icing on the cake: clicking the "1415 Puzzle" world window to try again to close it now crashes the VM(!). At least 4 separate bugs here. * In 15-Puzzle 1.1: package install/startup constructs a Player56 with an integer in place of an IdentityDictionary in "scripts" ivar (ivar defined in superclass Player). * Somehow, this causes a corrupt CompiledMethod for Player57>>setEmptyCell: to exist. Curiously, a normal version coexists with it! I suspect this is a VM error involving a dangling pointer. This may in turn indicate a Slang-to-C translator error. * In VM, something that causes a crash. It is probably the same or another dangling pointer. * In system tools: a single corrupt CompiledMethod makes "senders of" functionality useless. No failover. ("Proceed" causes the same corrupt method to keep popping up errors, apparently in an infinite loop.) In the particular case caused by the 15 puzzle, the CompiledMethod ends up with a "numLiterals" of zero (the proximate cause of the primitive failure) and a class that is an integer instead of a Class, FWIW. In any event, the system tools should provide some ability to recover, perhaps by ignoring or logging corrupt methods. 15 puzzle bug (generated bug report for the error during install): 10 January 2007 2:52:02 am VM: Win32 - a SmalltalkImage Image: Squeak3.9 [latest update: #7067] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir C:\squeak Trusted Dir C:\squeak\HP_Administrator Untrusted Dir C:\My Squeak\HP_Administrator SmallInteger(Object)>>doesNotUnderstand: #removeKey:ifAbsent: Receiver: 89276551 Arguments and temporary variables: aMessage: removeKey: nil ifAbsent: [] in Player56 class(Player class)>>cleanseS...etc... Receiver's instance variables: 89276551 Player56 class(Player class)>>cleanseScriptsOfNilKeys Receiver: Player56 Arguments and temporary variables: Receiver's instance variables: superclass: Player methodDict: a MethodDictionary(#moveNumber->a CompiledMethod (1619) ) format: 136 instanceVariables: nil organization: ('scripts' moveNumber) subclasses: nil name: #Player56 classPool: nil sharedPools: nil environment: a SystemDictionary(lots of globals) category: #UserObjects traitComposition: an IdentityDictionary(#moveNumber->A UniclassScript - selecto...etc... localSelectors: an IdentityDictionary() scripts: <<error during printing>> Player56 class(Player class)>>scripts Receiver: Player56 Arguments and temporary variables: Receiver's instance variables: superclass: Player methodDict: a MethodDictionary(#moveNumber->a CompiledMethod (1619) ) format: 136 instanceVariables: nil organization: ('scripts' moveNumber) subclasses: nil name: #Player56 classPool: nil sharedPools: nil environment: a SystemDictionary(lots of globals) category: #UserObjects traitComposition: an IdentityDictionary(#moveNumber->A UniclassScript - selecto...etc... localSelectors: an IdentityDictionary() scripts: <<error during printing>> Player56(Player)>>methodInterfacesForScriptsCategoryIn: Receiver: a Player56 (3795) named Cell16 Arguments and temporary variables: aVocabulary: an EToyVocabulary named "eToy" myScripts: nil us: nil Receiver's instance variables: dependents: nil costume: a PasteUpMorph<Cell16>(2009) costumes: nil --- The full stack --- SmallInteger(Object)>>doesNotUnderstand: #removeKey:ifAbsent: Player56 class(Player class)>>cleanseScriptsOfNilKeys Player56 class(Player class)>>scripts Player56(Player)>>methodInterfacesForScriptsCategoryIn: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Player56(Object)>>methodInterfacesForCategory:inVocabulary:limitClass: Player56(Object)>>tilePhrasesForCategory:inViewer: CategoryViewer>>categoryWording: CategoryViewer>>chosenCategorySymbol: CategoryViewer>>chooseCategoryWhoseTranslatedWordingIs: CategoryViewer>>initializeFor:categoryChoice: StandardViewer>>categoryViewerFor: StandardViewer>>addCategoryViewerFor:atEnd: StandardViewer>>addCategoryViewerFor: StandardViewer>>addCategoryViewer StandardViewer>>initializeFor:barHeight:includeDismissButton:showCategories: StandardViewer>>initializeFor:barHeight:includeDismissButton: StandardViewer>>initializeFor:barHeight: Presenter>>viewMorph: ViewerFlapTab>>unhibernate ViewerFlapTab(FlapTab)>>adaptToWorld [] in PasteUpMorph>>installFlaps {[:aFlapTab | aFlapTab adaptToWorld]} OrderedCollection>>do: PasteUpMorph>>installFlaps PasteUpMorph>>install Project>>enter:revert:saveForRevert: Project>>enter ProjectEntryNotification>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: ProjectEntryNotification(Exception)>>signal ProjectEntryNotification(Exception)>>signal: ProjectEntryNotification class>>signal: ProjectLoading class>>openName:stream:fromDirectory:withProjectView: [] in ProjectLoading class>>openFromDirectory:andFileName: {[ProgressNotification signal: '1:foundMostRecent'. fileAndDir := self bestA...]} BlockContext>>on:do: [] in ComplexProgressIndicator>>withProgressDo: {[aBlock on: ProgressInitiationException do: [:ex | ex sendNotificati...]} BlockContext>>on:do: ComplexProgressIndicator>>withProgressDo: ProjectLoading class>>openFromDirectory:andFileName: [] in SMProjectInstaller>>install {[ProjectLoading openFromDirectory: dir andFileName: fileName]} ...etc... The VM crash log curiously indicates the VM version to be quite a bit earlier than 3.9. Possible there's a mismatch between squeak-dev and squeak? I downloaded the latest of both, after determining that squeak-dev by itself was not a complete Squeak install. In fact, there's an even more embarrassing fifth bug -- install just Squeak 3.9 7067 directly from the zip to any directory, drag the 7067 image into the executable, click Workspace, and click "SMLoader open" in Workspace -- guess what? SmallInteger doesNotUnderstand: #numbers ... is there a pattern here? Everything seems to boil down to SmallIntegers in places where they don't belong. I'm starting to suspect that the system is mistaking object pointers for integers and integers for object pointers here and there. That would explain everything, including the VM crashes. It would also betray a serious lack of testing and polish, unless it's a weird system-dependent bug, but Squeak should be well tested on x86 boxen. FWIW, system specs are: CPU: AMD64 dual-core XP2000 OS: Windows XP MCE, 32-bit, SP2 Video: eVGA -> nVidia GeForce GS6800 Sound: some generic POS, not actually exercised in the occurring of these crashes Memory: about 3/4 of 1GB in use and 1/4 free according to Task Manager Disk: about 2/5 of 250GB free Version of Squeak downloaded was Win32 (I didn't see a win64 one anyway, not that it would likely have worked). Log from an instance of the VM crash: --------------------------------------------------------------------- Wed Jan 10 02:38:50 2007 Exception code: C0000005 Exception addr: 00412165 Access violation (read access) at 054DFFC8 EAX:054DFFC8 EBX:0267441C ECX:026795C4 EDX:00000000 ESI:005203F0 EDI:018DED7C EBP:0006FC50 ESP:0006FC1C EIP:00412165 EFL:00010212 FP Control: FFFF037F FP Status: FFFF4020 FP Tag: FFFFFFFF VM Version: Squeak 3.7.1 (release) from Sep 23 2004 Compiler: gcc 2.95.2 19991024 (release) Current byte code: 209 Primitive index: 77 Loaded plugins: DSAPrims 23 September 2004 (i) ZipPlugin 23 September 2004 (i) SocketPlugin 23 September 2004 (i) LargeIntegers v1.3 23 September 2004 (i) Matrix2x3Plugin 23 September 2004 (i) FloatArrayPlugin 23 September 2004 (i) B2DPlugin 23 September 2004 (i) BitBltPlugin 23 September 2004 (i) SecurityPlugin 23 September 2004 (i) FilePlugin 23 September 2004 (i) MiscPrimitivePlugin 23 September 2004 (i) Stack dump: 53568028 Behavior>allInstancesDo: 53567116 Behavior>allSubInstancesDo: 53567684 [] in Project>enter:revert:saveForRevert: 53566956 Dictionary>at:ifPresentAndInMemory: 48568348 Project>enter:revert:saveForRevert: 48569980 ProjectViewMorph>enter 48569888 ProjectViewMorph>mouseUp: 48569756 Morph>handleMouseUp: 48569664 MouseButtonEvent>sentTo: 48569572 Morph>handleEvent: 48569204 Morph>handleFocusEvent: 48569296 [] in HandMorph>sendFocusEvent:to:clear: 48569388 [] in PasteUpMorph>becomeActiveDuring: 48569112 BlockContext>on:do: 48569020 PasteUpMorph>becomeActiveDuring: 48568836 HandMorph>sendFocusEvent:to:clear: 48568744 HandMorph>sendEvent:focus:clear: 48568652 HandMorph>sendMouseEvent: 48568256 HandMorph>handleEvent: 48567936 HandMorph>processEvents 48568028 [] in WorldState>doOneCycleNowFor: 48567844 SequenceableCollection>do: 48567752 WorldState>handsDo: 48567660 WorldState>doOneCycleNowFor: 48567568 WorldState>doOneCycleFor: 48567476 PasteUpMorph>doOneCycle 48216052 [] in >spawnNewProcess 48216236 [] in BlockContext>newProcess --------------------------------------------------------------------- Wed Jan 10 03:02:09 2007 Exception code: C0000005 Exception addr: 00427242 Access violation (read access) at 15797480 EAX:0ABCBA40 EBX:81BF3194 ECX:026C99E0 EDX:026CD798 ESI:00001378 EDI:00520580 EBP:00520580 ESP:0006FB64 EIP:00427242 EFL:00010202 FP Control: FFFF037F FP Status: FFFF0120 FP Tag: FFFFFFFF VM Version: Squeak 3.7.1 (release) from Sep 23 2004 Compiler: gcc 2.95.2 19991024 (release) Current byte code: 46 Primitive index: 71 Loaded plugins: SocketPlugin 23 September 2004 (i) ZipPlugin 23 September 2004 (i) DSAPrims 23 September 2004 (i) LargeIntegers v1.3 23 September 2004 (i) Matrix2x3Plugin 23 September 2004 (i) FloatArrayPlugin 23 September 2004 (i) B2DPlugin 23 September 2004 (i) BitBltPlugin 23 September 2004 (i) SecurityPlugin 23 September 2004 (i) FilePlugin 23 September 2004 (i) MiscPrimitivePlugin 23 September 2004 (i) Stack dump: |
Nice analysis but there is really only one problem: By changing the
metaclass structure 3.9 breaks all projects that use eToys scripting. This is a well-known problem and has really nothing to do with the level of stability claimed for the project at SqueakMap - none of the projects that were made for <3.9 will work in 3.9 proper if they involve scripting. Cheers, - Andreas John Ersatznom wrote: > Despite: "Maturity level/Rock solid - Useable and hasn't had bugs for a > long time." > > The following occurs reproducibly on a bog-standard winXPSP2 box: > > * Install Squeak3.9-final-7067 > * Install squeak-dev-72-2 > * Launch squeak-dev-72-2.image > * World menu -> old desktop menu -> open ... -> SqueakMap Package Loader > * Select 15-Puzzle (-> 1.1) > * Menu -> first two items are "install" and "email package maintainers" > * Latter produces the "gaelli@" email address I'm copying this to > * Former produces "error occurred during install". Puzzle appears anyway > * Scramble and unscramble puzzle works normally > * World menu -> old desktop menu -> previous project returns to main > world > * There a debugger can be seen. Bug report below. Upshot: seems a > Player56 instance's scripts ivar is ending up an integer instead of an > IdentityDictionary. > * Open a system browser and find some method. Pick senders of. Pick a > method. Witness "primitive failed" debugger. > * Cause is a corrupt CompiledMethod object; senders grovels over all > compiled methods in the system. This particular CompiledMethod object > is for Player57's setEmptyCell: method. > * Yes -- that would be *your* Player57 class, Gaelli. :) > * To recover normal behavior, unloading the "1415 Puzzle" world seems > called-for. X the window and get another attempt to invoke an > IdentityDictionary method on a SmallInteger. > * Do a little digging and discover that Player56 can have its "scripts" > ivar reset with jettisonScripts > * Open an inspector on the Player56 instance causing all the trouble and > eval "self jettisonScripts" > * The icing on the cake: clicking the "1415 Puzzle" world window to try > again to close it now crashes the VM(!). > > At least 4 separate bugs here. > * In 15-Puzzle 1.1: package install/startup constructs a Player56 with > an integer in place of an IdentityDictionary in "scripts" ivar (ivar > defined in superclass Player). > * Somehow, this causes a corrupt CompiledMethod for > Player57>>setEmptyCell: to exist. Curiously, a normal version coexists > with it! I suspect this is a VM error involving a dangling pointer. > This may in turn indicate a Slang-to-C translator error. > * In VM, something that causes a crash. It is probably the same or > another dangling pointer. > * In system tools: a single corrupt CompiledMethod makes "senders of" > functionality useless. No failover. ("Proceed" causes the same corrupt > method to keep popping up errors, apparently in an infinite loop.) > In the particular case caused by the 15 puzzle, the CompiledMethod > ends up with a "numLiterals" of zero (the proximate cause of the > primitive failure) and a class that is an integer instead of a Class, > FWIW. In any event, the system tools should provide some ability to > recover, perhaps by ignoring or logging corrupt methods. > > 15 puzzle bug (generated bug report for the error during install): > > 10 January 2007 2:52:02 am > > VM: Win32 - a SmalltalkImage > Image: Squeak3.9 [latest update: #7067] > > SecurityManager state: > Restricted: false > FileAccess: true > SocketAccess: true > Working Dir C:\squeak > Trusted Dir C:\squeak\HP_Administrator > Untrusted Dir C:\My Squeak\HP_Administrator > > SmallInteger(Object)>>doesNotUnderstand: #removeKey:ifAbsent: > Receiver: 89276551 > Arguments and temporary variables: > aMessage: removeKey: nil ifAbsent: [] in Player56 > class(Player class)>>cleanseS...etc... > Receiver's instance variables: > 89276551 > > Player56 class(Player class)>>cleanseScriptsOfNilKeys > Receiver: Player56 > Arguments and temporary variables: > > Receiver's instance variables: > superclass: Player > methodDict: a MethodDictionary(#moveNumber->a CompiledMethod > (1619) ) > format: 136 > instanceVariables: nil > organization: ('scripts' moveNumber) > > subclasses: nil > name: #Player56 > classPool: nil > sharedPools: nil > environment: a SystemDictionary(lots of globals) > category: #UserObjects > traitComposition: an IdentityDictionary(#moveNumber->A > UniclassScript - selecto...etc... > localSelectors: an IdentityDictionary() > scripts: <<error during printing>> > > Player56 class(Player class)>>scripts > Receiver: Player56 > Arguments and temporary variables: > > Receiver's instance variables: > superclass: Player > methodDict: a MethodDictionary(#moveNumber->a CompiledMethod > (1619) ) > format: 136 > instanceVariables: nil > organization: ('scripts' moveNumber) > > subclasses: nil > name: #Player56 > classPool: nil > sharedPools: nil > environment: a SystemDictionary(lots of globals) > category: #UserObjects > traitComposition: an IdentityDictionary(#moveNumber->A > UniclassScript - selecto...etc... > localSelectors: an IdentityDictionary() > scripts: <<error during printing>> > > Player56(Player)>>methodInterfacesForScriptsCategoryIn: > Receiver: a Player56 (3795) named Cell16 > Arguments and temporary variables: > aVocabulary: an EToyVocabulary named "eToy" > myScripts: nil > us: nil > Receiver's instance variables: > dependents: nil > costume: a PasteUpMorph<Cell16>(2009) > costumes: nil > > > --- The full stack --- > SmallInteger(Object)>>doesNotUnderstand: #removeKey:ifAbsent: > Player56 class(Player class)>>cleanseScriptsOfNilKeys > Player56 class(Player class)>>scripts > Player56(Player)>>methodInterfacesForScriptsCategoryIn: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Player56(Object)>>methodInterfacesForCategory:inVocabulary:limitClass: > Player56(Object)>>tilePhrasesForCategory:inViewer: > CategoryViewer>>categoryWording: > CategoryViewer>>chosenCategorySymbol: > CategoryViewer>>chooseCategoryWhoseTranslatedWordingIs: > CategoryViewer>>initializeFor:categoryChoice: > StandardViewer>>categoryViewerFor: > StandardViewer>>addCategoryViewerFor:atEnd: > StandardViewer>>addCategoryViewerFor: > StandardViewer>>addCategoryViewer > StandardViewer>>initializeFor:barHeight:includeDismissButton:showCategories: > > StandardViewer>>initializeFor:barHeight:includeDismissButton: > StandardViewer>>initializeFor:barHeight: > Presenter>>viewMorph: > ViewerFlapTab>>unhibernate > ViewerFlapTab(FlapTab)>>adaptToWorld > [] in PasteUpMorph>>installFlaps {[:aFlapTab | aFlapTab adaptToWorld]} > OrderedCollection>>do: > PasteUpMorph>>installFlaps > PasteUpMorph>>install > Project>>enter:revert:saveForRevert: > Project>>enter > ProjectEntryNotification>>defaultAction > UndefinedObject>>handleSignal: > MethodContext(ContextPart)>>handleSignal: > MethodContext(ContextPart)>>handleSignal: > MethodContext(ContextPart)>>handleSignal: > MethodContext(ContextPart)>>handleSignal: > MethodContext(ContextPart)>>handleSignal: > ProjectEntryNotification(Exception)>>signal > ProjectEntryNotification(Exception)>>signal: > ProjectEntryNotification class>>signal: > ProjectLoading class>>openName:stream:fromDirectory:withProjectView: > [] in ProjectLoading class>>openFromDirectory:andFileName: > {[ProgressNotification signal: '1:foundMostRecent'. fileAndDir := self > bestA...]} > BlockContext>>on:do: > [] in ComplexProgressIndicator>>withProgressDo: {[aBlock on: > ProgressInitiationException do: [:ex | ex sendNotificati...]} > BlockContext>>on:do: > ComplexProgressIndicator>>withProgressDo: > ProjectLoading class>>openFromDirectory:andFileName: > [] in SMProjectInstaller>>install {[ProjectLoading openFromDirectory: > dir andFileName: fileName]} > ...etc... > > > > The VM crash log curiously indicates the VM version to be quite a bit > earlier than 3.9. Possible there's a mismatch between squeak-dev and > squeak? I downloaded the latest of both, after determining that > squeak-dev by itself was not a complete Squeak install. In fact, there's > an even more embarrassing fifth bug -- install just Squeak 3.9 7067 > directly from the zip to any directory, drag the 7067 image into the > executable, click Workspace, and click "SMLoader open" in Workspace -- > guess what? SmallInteger doesNotUnderstand: #numbers ... is there a > pattern here? Everything seems to boil down to SmallIntegers in places > where they don't belong. I'm starting to suspect that the system is > mistaking object pointers for integers and integers for object pointers > here and there. That would explain everything, including the VM crashes. > It would also betray a serious lack of testing and polish, unless it's a > weird system-dependent bug, but Squeak should be well tested on x86 boxen. > > FWIW, system specs are: > CPU: AMD64 dual-core XP2000 > OS: Windows XP MCE, 32-bit, SP2 > Video: eVGA -> nVidia GeForce GS6800 > Sound: some generic POS, not actually exercised in the occurring of > these crashes > Memory: about 3/4 of 1GB in use and 1/4 free according to Task Manager > Disk: about 2/5 of 250GB free > > Version of Squeak downloaded was Win32 (I didn't see a win64 one anyway, > not that it would likely have worked). > > Log from an instance of the VM crash: > > --------------------------------------------------------------------- > Wed Jan 10 02:38:50 2007 > > Exception code: C0000005 > Exception addr: 00412165 > Access violation (read access) at 054DFFC8 > EAX:054DFFC8 EBX:0267441C ECX:026795C4 EDX:00000000 > ESI:005203F0 EDI:018DED7C EBP:0006FC50 ESP:0006FC1C > EIP:00412165 EFL:00010212 > FP Control: FFFF037F > FP Status: FFFF4020 > FP Tag: FFFFFFFF > VM Version: Squeak 3.7.1 (release) from Sep 23 2004 > Compiler: gcc 2.95.2 19991024 (release) > > Current byte code: 209 > Primitive index: 77 > > Loaded plugins: > DSAPrims 23 September 2004 (i) > ZipPlugin 23 September 2004 (i) > SocketPlugin 23 September 2004 (i) > LargeIntegers v1.3 23 September 2004 (i) > Matrix2x3Plugin 23 September 2004 (i) > FloatArrayPlugin 23 September 2004 (i) > B2DPlugin 23 September 2004 (i) > BitBltPlugin 23 September 2004 (i) > SecurityPlugin 23 September 2004 (i) > FilePlugin 23 September 2004 (i) > MiscPrimitivePlugin 23 September 2004 (i) > > > Stack dump: > > 53568028 Behavior>allInstancesDo: > 53567116 Behavior>allSubInstancesDo: > 53567684 [] in Project>enter:revert:saveForRevert: > 53566956 Dictionary>at:ifPresentAndInMemory: > 48568348 Project>enter:revert:saveForRevert: > 48569980 ProjectViewMorph>enter > 48569888 ProjectViewMorph>mouseUp: > 48569756 Morph>handleMouseUp: > 48569664 MouseButtonEvent>sentTo: > 48569572 Morph>handleEvent: > 48569204 Morph>handleFocusEvent: > 48569296 [] in HandMorph>sendFocusEvent:to:clear: > 48569388 [] in PasteUpMorph>becomeActiveDuring: > 48569112 BlockContext>on:do: > 48569020 PasteUpMorph>becomeActiveDuring: > 48568836 HandMorph>sendFocusEvent:to:clear: > 48568744 HandMorph>sendEvent:focus:clear: > 48568652 HandMorph>sendMouseEvent: > 48568256 HandMorph>handleEvent: > 48567936 HandMorph>processEvents > 48568028 [] in WorldState>doOneCycleNowFor: > 48567844 SequenceableCollection>do: > 48567752 WorldState>handsDo: > 48567660 WorldState>doOneCycleNowFor: > 48567568 WorldState>doOneCycleFor: > 48567476 PasteUpMorph>doOneCycle > 48216052 [] in >spawnNewProcess > 48216236 [] in BlockContext>newProcess > > --------------------------------------------------------------------- > Wed Jan 10 03:02:09 2007 > > Exception code: C0000005 > Exception addr: 00427242 > Access violation (read access) at 15797480 > EAX:0ABCBA40 EBX:81BF3194 ECX:026C99E0 EDX:026CD798 > ESI:00001378 EDI:00520580 EBP:00520580 ESP:0006FB64 > EIP:00427242 EFL:00010202 > FP Control: FFFF037F > FP Status: FFFF0120 > FP Tag: FFFFFFFF > VM Version: Squeak 3.7.1 (release) from Sep 23 2004 > Compiler: gcc 2.95.2 19991024 (release) > > Current byte code: 46 > Primitive index: 71 > > Loaded plugins: > SocketPlugin 23 September 2004 (i) > ZipPlugin 23 September 2004 (i) > DSAPrims 23 September 2004 (i) > LargeIntegers v1.3 23 September 2004 (i) > Matrix2x3Plugin 23 September 2004 (i) > FloatArrayPlugin 23 September 2004 (i) > B2DPlugin 23 September 2004 (i) > BitBltPlugin 23 September 2004 (i) > SecurityPlugin 23 September 2004 (i) > FilePlugin 23 September 2004 (i) > MiscPrimitivePlugin 23 September 2004 (i) > > > Stack dump: > > > > |
In reply to this post by John Ersatznom
Andreas Raab wrote:
> Nice analysis but there is really only one problem: By changing the > metaclass structure 3.9 breaks all projects that use eToys scripting. > This is a well-known problem and has really nothing to do with the > level of stability claimed for the project at SqueakMap - none of the > projects that were made for <3.9 will work in 3.9 proper if they > involve scripting. I'm dubious that the VM should crash because of this. In fact, on further investigation, almost nothing in SqueakMap appears to work as intended. This includes installing e.g. LookEnhancements, or almost anything else (nothing I tried installed cleanly and worked, and a lot of things produced the recovery console thingie, although only the 15 puzzle was able to provoke an actual direct abort). If 3.9 is basically not compatible with the whole preexisting codebase (right down to its VM), then there's a serious problem. At minimim, SqueakMap on 3.9 should show a bright red alert on any package that won't be compatible. Given the indications that in fact none are compatible besides what comes with 3.9, perhaps SqueakMap needs to fork into the existing map and a new one for things that actually work in current and future versions of Squeak? With the 3.9 SqueakMap package loader showing the latter. Existing projects that are compatible (if any) would be copied over of course, and developers of packages that aren't compatible encouraged to update them. A second problem is that I didn't find anywhere documenting this as a "known issue". There's no mention on the wiki or the main Squeak pages of this, and everything that mentions VM crashes indicates that they should be extremely rare and "unlikely to be triggered by Squeak code", among other things. (Experimental VMs notwithstanding.) A Google search for squeak 3.9 "VM crash" turned up next to nil and no mention of 3.9 being incompatible with large chunks of the existing application base. This should be documented more prominently. A particular problem is that a new user can very easily b0rk the entire system in the present state of things. Consider: * A fresh install and running the default image produces a welcome page with a prominent link to open the package loader and encouragement to do so. * Nothing (that I could find) in the package loader actually works with 3.9 and, worse, they tend to screw the entire image up rather than simply not working themselves. * The first item in the package loader, alphabetically, is -- you guessed it -- the 15 puzzle. The one that can actually outright crash the VM. It's not hard to guess the results. And a non-techie is likely to conclude after a bit of fiddling that "this thing is quite unstable and not ready for primetime yet", although that actually only seems to be true if they use the package loader. :) Of course, a non-techie might also make the mistake of loading a package, then (assuming things don't crash first) exiting and answering "yes" to the save prompt. If they simply unzipped Squeak 3.9 and then double-clicked the executable, as is likely, then they've probably just mangled the Squeak3.9-final-7067.image file and things won't work right without a reinstall. That is sure to make a good impression. Recommendation: I'm not sure. If there's a simple tweak to 3.9 to restore back compatibility with older packages, the obvious, but if there's such a simple tweak it would probably have already been done. If there's not? I dunno...Boils down to a documentation/hide broken packages from the user type issue I guess. P.S. I got suspicious at the length of time without a reply and checked the mailing list archives. That is the only place where your reply appeared. Suggest using "reply to all" to send to the user as well as the list. Also, list admins might want to look into a more complex munge of the addresses in the archives, as well. I could write a bot that parses "foo at bar.baz" as well as "[hidden email]" in a heartbeat and it's common enough now to be worth including such a feature in a harvester. I'm not that evil, but I'm sure there's someone equally capable that is, somewhere... |
In reply to this post by Andreas.Raab
On 2007 January 10 11:13, Andreas Raab wrote:
> Nice analysis but there is really only one problem: By changing the > metaclass structure 3.9 breaks all projects that use eToys scripting. Wow .. Andreas, thanks for pointing it out. I did not realize that throughout 3.9, that even a completely basic eToys project with a script created in pre-3.9 does not import into 3.9 (I just tried and failed a very simple project from 3.8 to 3.9). The reason I am interested in this is 3.10. If I understand correctly, there is a plan to make (and Pavel has some level of progress in that direction) eToys and Morphic unloadable and re-loadable. I started writing a set of basic eToys tests, with the idea that should help as automated tests to verify that eToys work after re-loading. (I do not hope my tests will be more than a drop in the ocean, but that is the general idea). Now I am thinking, does that even make sense, what likelyhood is there there are even a few people interested using eToys in 3.9 and above, when projects are unportable. Just at the time when OLPC could help eToys and Squeak become much more visible (and hopefully feeding visibility back to more people creating software for kids), we have this situation of virtually no two eToys sytems can exchange projects. (I had a problem loading an eToy project from Squeakland to OLPC, but I believe that was a specific complexity in that project and simple projects can be exchanged). Hopefully these problems will turn to something good though, if the re-loadability of eToys is succesful in 3.10, perhaps the same process could be used in Squeakland/OLPC to maintain a "shared" version of eToys ... I'd like to hear any opinions if this is somewhat realistic hope (or not) ... Thanks Milan > This is a well-known problem and has really nothing to do with the level > of stability claimed for the project at SqueakMap - none of the projects > that were made for <3.9 will work in 3.9 proper if they involve scripting. > > Cheers, > - Andreas > > John Ersatznom wrote: > > Despite: "Maturity level/Rock solid - Useable and hasn't had bugs for a > > long time." > > > > The following occurs reproducibly on a bog-standard winXPSP2 box: > > > > * Install Squeak3.9-final-7067 > > * Install squeak-dev-72-2 > > * Launch squeak-dev-72-2.image > > * World menu -> old desktop menu -> open ... -> SqueakMap Package Loader > > * Select 15-Puzzle (-> 1.1) > > * Menu -> first two items are "install" and "email package maintainers" > > * Latter produces the "gaelli@" email address I'm copying this to > > * Former produces "error occurred during install". Puzzle appears anyway > > * Scramble and unscramble puzzle works normally > > * World menu -> old desktop menu -> previous project returns to main > > world > > * There a debugger can be seen. Bug report below. Upshot: seems a > > Player56 instance's scripts ivar is ending up an integer instead of an > > IdentityDictionary. > > * Open a system browser and find some method. Pick senders of. Pick a > > method. Witness "primitive failed" debugger. > > * Cause is a corrupt CompiledMethod object; senders grovels over all > > compiled methods in the system. This particular CompiledMethod object > > is for Player57's setEmptyCell: method. > > * Yes -- that would be *your* Player57 class, Gaelli. :) > > * To recover normal behavior, unloading the "1415 Puzzle" world seems > > called-for. X the window and get another attempt to invoke an > > IdentityDictionary method on a SmallInteger. > > * Do a little digging and discover that Player56 can have its "scripts" > > ivar reset with jettisonScripts > > * Open an inspector on the Player56 instance causing all the trouble and > > eval "self jettisonScripts" > > * The icing on the cake: clicking the "1415 Puzzle" world window to try > > again to close it now crashes the VM(!). > > > > At least 4 separate bugs here. > > * In 15-Puzzle 1.1: package install/startup constructs a Player56 with > > an integer in place of an IdentityDictionary in "scripts" ivar (ivar > > defined in superclass Player). > > * Somehow, this causes a corrupt CompiledMethod for > > Player57>>setEmptyCell: to exist. Curiously, a normal version coexists > > with it! I suspect this is a VM error involving a dangling pointer. > > This may in turn indicate a Slang-to-C translator error. > > * In VM, something that causes a crash. It is probably the same or > > another dangling pointer. > > * In system tools: a single corrupt CompiledMethod makes "senders of" > > functionality useless. No failover. ("Proceed" causes the same corrupt > > method to keep popping up errors, apparently in an infinite loop.) > > In the particular case caused by the 15 puzzle, the CompiledMethod > > ends up with a "numLiterals" of zero (the proximate cause of the > > primitive failure) and a class that is an integer instead of a Class, > > FWIW. In any event, the system tools should provide some ability to > > recover, perhaps by ignoring or logging corrupt methods. > > > > 15 puzzle bug (generated bug report for the error during install): > > > > 10 January 2007 2:52:02 am > > > > VM: Win32 - a SmalltalkImage > > Image: Squeak3.9 [latest update: #7067] > > > > SecurityManager state: > > Restricted: false > > FileAccess: true > > SocketAccess: true > > Working Dir C:\squeak > > Trusted Dir C:\squeak\HP_Administrator > > Untrusted Dir C:\My Squeak\HP_Administrator > > > > SmallInteger(Object)>>doesNotUnderstand: #removeKey:ifAbsent: > > Receiver: 89276551 > > Arguments and temporary variables: > > aMessage: removeKey: nil ifAbsent: [] in Player56 > > class(Player class)>>cleanseS...etc... > > Receiver's instance variables: > > 89276551 > > > > Player56 class(Player class)>>cleanseScriptsOfNilKeys > > Receiver: Player56 > > Arguments and temporary variables: > > > > Receiver's instance variables: > > superclass: Player > > methodDict: a MethodDictionary(#moveNumber->a CompiledMethod > > (1619) ) > > format: 136 > > instanceVariables: nil > > organization: ('scripts' moveNumber) > > > > subclasses: nil > > name: #Player56 > > classPool: nil > > sharedPools: nil > > environment: a SystemDictionary(lots of globals) > > category: #UserObjects > > traitComposition: an IdentityDictionary(#moveNumber->A > > UniclassScript - selecto...etc... > > localSelectors: an IdentityDictionary() > > scripts: <<error during printing>> > > > > Player56 class(Player class)>>scripts > > Receiver: Player56 > > Arguments and temporary variables: > > > > Receiver's instance variables: > > superclass: Player > > methodDict: a MethodDictionary(#moveNumber->a CompiledMethod > > (1619) ) > > format: 136 > > instanceVariables: nil > > organization: ('scripts' moveNumber) > > > > subclasses: nil > > name: #Player56 > > classPool: nil > > sharedPools: nil > > environment: a SystemDictionary(lots of globals) > > category: #UserObjects > > traitComposition: an IdentityDictionary(#moveNumber->A > > UniclassScript - selecto...etc... > > localSelectors: an IdentityDictionary() > > scripts: <<error during printing>> > > > > Player56(Player)>>methodInterfacesForScriptsCategoryIn: > > Receiver: a Player56 (3795) named Cell16 > > Arguments and temporary variables: > > aVocabulary: an EToyVocabulary named "eToy" > > myScripts: nil > > us: nil > > Receiver's instance variables: > > dependents: nil > > costume: a PasteUpMorph<Cell16>(2009) > > costumes: nil > > > > > > --- The full stack --- > > SmallInteger(Object)>>doesNotUnderstand: #removeKey:ifAbsent: > > Player56 class(Player class)>>cleanseScriptsOfNilKeys > > Player56 class(Player class)>>scripts > > Player56(Player)>>methodInterfacesForScriptsCategoryIn: > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Player56(Object)>>methodInterfacesForCategory:inVocabulary:limitClass: > > Player56(Object)>>tilePhrasesForCategory:inViewer: > > CategoryViewer>>categoryWording: > > CategoryViewer>>chosenCategorySymbol: > > CategoryViewer>>chooseCategoryWhoseTranslatedWordingIs: > > CategoryViewer>>initializeFor:categoryChoice: > > StandardViewer>>categoryViewerFor: > > StandardViewer>>addCategoryViewerFor:atEnd: > > StandardViewer>>addCategoryViewerFor: > > StandardViewer>>addCategoryViewer > > StandardViewer>>initializeFor:barHeight:includeDismissButton:showCategori > >es: > > > > StandardViewer>>initializeFor:barHeight:includeDismissButton: > > StandardViewer>>initializeFor:barHeight: > > Presenter>>viewMorph: > > ViewerFlapTab>>unhibernate > > ViewerFlapTab(FlapTab)>>adaptToWorld > > [] in PasteUpMorph>>installFlaps {[:aFlapTab | aFlapTab adaptToWorld]} > > OrderedCollection>>do: > > PasteUpMorph>>installFlaps > > PasteUpMorph>>install > > Project>>enter:revert:saveForRevert: > > Project>>enter > > ProjectEntryNotification>>defaultAction > > UndefinedObject>>handleSignal: > > MethodContext(ContextPart)>>handleSignal: > > MethodContext(ContextPart)>>handleSignal: > > MethodContext(ContextPart)>>handleSignal: > > MethodContext(ContextPart)>>handleSignal: > > MethodContext(ContextPart)>>handleSignal: > > ProjectEntryNotification(Exception)>>signal > > ProjectEntryNotification(Exception)>>signal: > > ProjectEntryNotification class>>signal: > > ProjectLoading class>>openName:stream:fromDirectory:withProjectView: > > [] in ProjectLoading class>>openFromDirectory:andFileName: > > {[ProgressNotification signal: '1:foundMostRecent'. fileAndDir := self > > bestA...]} > > BlockContext>>on:do: > > [] in ComplexProgressIndicator>>withProgressDo: {[aBlock on: > > ProgressInitiationException do: [:ex | ex sendNotificati...]} > > BlockContext>>on:do: > > ComplexProgressIndicator>>withProgressDo: > > ProjectLoading class>>openFromDirectory:andFileName: > > [] in SMProjectInstaller>>install {[ProjectLoading openFromDirectory: > > dir andFileName: fileName]} > > ...etc... > > > > > > > > The VM crash log curiously indicates the VM version to be quite a bit > > earlier than 3.9. Possible there's a mismatch between squeak-dev and > > squeak? I downloaded the latest of both, after determining that > > squeak-dev by itself was not a complete Squeak install. In fact, there's > > an even more embarrassing fifth bug -- install just Squeak 3.9 7067 > > directly from the zip to any directory, drag the 7067 image into the > > executable, click Workspace, and click "SMLoader open" in Workspace -- > > guess what? SmallInteger doesNotUnderstand: #numbers ... is there a > > pattern here? Everything seems to boil down to SmallIntegers in places > > where they don't belong. I'm starting to suspect that the system is > > mistaking object pointers for integers and integers for object pointers > > here and there. That would explain everything, including the VM crashes. > > It would also betray a serious lack of testing and polish, unless it's a > > weird system-dependent bug, but Squeak should be well tested on x86 > > boxen. > > > > FWIW, system specs are: > > CPU: AMD64 dual-core XP2000 > > OS: Windows XP MCE, 32-bit, SP2 > > Video: eVGA -> nVidia GeForce GS6800 > > Sound: some generic POS, not actually exercised in the occurring of > > these crashes > > Memory: about 3/4 of 1GB in use and 1/4 free according to Task Manager > > Disk: about 2/5 of 250GB free > > > > Version of Squeak downloaded was Win32 (I didn't see a win64 one anyway, > > not that it would likely have worked). > > > > Log from an instance of the VM crash: > > > > --------------------------------------------------------------------- > > Wed Jan 10 02:38:50 2007 > > > > Exception code: C0000005 > > Exception addr: 00412165 > > Access violation (read access) at 054DFFC8 > > EAX:054DFFC8 EBX:0267441C ECX:026795C4 EDX:00000000 > > ESI:005203F0 EDI:018DED7C EBP:0006FC50 ESP:0006FC1C > > EIP:00412165 EFL:00010212 > > FP Control: FFFF037F > > FP Status: FFFF4020 > > FP Tag: FFFFFFFF > > VM Version: Squeak 3.7.1 (release) from Sep 23 2004 > > Compiler: gcc 2.95.2 19991024 (release) > > > > Current byte code: 209 > > Primitive index: 77 > > > > Loaded plugins: > > DSAPrims 23 September 2004 (i) > > ZipPlugin 23 September 2004 (i) > > SocketPlugin 23 September 2004 (i) > > LargeIntegers v1.3 23 September 2004 (i) > > Matrix2x3Plugin 23 September 2004 (i) > > FloatArrayPlugin 23 September 2004 (i) > > B2DPlugin 23 September 2004 (i) > > BitBltPlugin 23 September 2004 (i) > > SecurityPlugin 23 September 2004 (i) > > FilePlugin 23 September 2004 (i) > > MiscPrimitivePlugin 23 September 2004 (i) > > > > > > Stack dump: > > > > 53568028 Behavior>allInstancesDo: > > 53567116 Behavior>allSubInstancesDo: > > 53567684 [] in Project>enter:revert:saveForRevert: > > 53566956 Dictionary>at:ifPresentAndInMemory: > > 48568348 Project>enter:revert:saveForRevert: > > 48569980 ProjectViewMorph>enter > > 48569888 ProjectViewMorph>mouseUp: > > 48569756 Morph>handleMouseUp: > > 48569664 MouseButtonEvent>sentTo: > > 48569572 Morph>handleEvent: > > 48569204 Morph>handleFocusEvent: > > 48569296 [] in HandMorph>sendFocusEvent:to:clear: > > 48569388 [] in PasteUpMorph>becomeActiveDuring: > > 48569112 BlockContext>on:do: > > 48569020 PasteUpMorph>becomeActiveDuring: > > 48568836 HandMorph>sendFocusEvent:to:clear: > > 48568744 HandMorph>sendEvent:focus:clear: > > 48568652 HandMorph>sendMouseEvent: > > 48568256 HandMorph>handleEvent: > > 48567936 HandMorph>processEvents > > 48568028 [] in WorldState>doOneCycleNowFor: > > 48567844 SequenceableCollection>do: > > 48567752 WorldState>handsDo: > > 48567660 WorldState>doOneCycleNowFor: > > 48567568 WorldState>doOneCycleFor: > > 48567476 PasteUpMorph>doOneCycle > > 48216052 [] in >spawnNewProcess > > 48216236 [] in BlockContext>newProcess > > > > --------------------------------------------------------------------- > > Wed Jan 10 03:02:09 2007 > > > > Exception code: C0000005 > > Exception addr: 00427242 > > Access violation (read access) at 15797480 > > EAX:0ABCBA40 EBX:81BF3194 ECX:026C99E0 EDX:026CD798 > > ESI:00001378 EDI:00520580 EBP:00520580 ESP:0006FB64 > > EIP:00427242 EFL:00010202 > > FP Control: FFFF037F > > FP Status: FFFF0120 > > FP Tag: FFFFFFFF > > VM Version: Squeak 3.7.1 (release) from Sep 23 2004 > > Compiler: gcc 2.95.2 19991024 (release) > > > > Current byte code: 46 > > Primitive index: 71 > > > > Loaded plugins: > > SocketPlugin 23 September 2004 (i) > > ZipPlugin 23 September 2004 (i) > > DSAPrims 23 September 2004 (i) > > LargeIntegers v1.3 23 September 2004 (i) > > Matrix2x3Plugin 23 September 2004 (i) > > FloatArrayPlugin 23 September 2004 (i) > > B2DPlugin 23 September 2004 (i) > > BitBltPlugin 23 September 2004 (i) > > SecurityPlugin 23 September 2004 (i) > > FilePlugin 23 September 2004 (i) > > MiscPrimitivePlugin 23 September 2004 (i) > > > > > > Stack dump: |
Free forum by Nabble | Edit this page |