Hi Esteban, On 07 Mar 2013, at 15:02, Esteban Lorenzano <estebanlm@gmail.com> wrote:

Hi Sven,

Could you try now, using ciPharoVMLatest.sh script? I included yesterday a fix for that bug from Eliot's... and it was working fine in my machine, I'm hoping that issue is solved.

Thanks for the quick response. I tried on the server and it still failed in the same way (in the mean time I upgraded to Ubuntu 12.04.2 LTS). But I was also trying the same in VirtualBox on my Mac, running a 32-bit 12.10 non-server Ubuntu. And there things worked fine immediately (I noticed the image was already updated ;-), no crash. I am still investigating, but it seems things changed in the Ubuntu universe regarding ia32-libs on 64 bit (it does no longer exist). Maybe that is a factor as well, I am not sure. Sven

Esteban

On Mar 7, 2013, at 2:17 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

On a Ubuntu 11.04 server I am getting VM crashes while loading code, always at the same place it seems.

This is what I did:

curl -L http://files.pharo.org/script/ciPharo20.sh | bash

curl -L http://files.pharo.org/script/ciPharoVM.sh | bash

./vm.sh Pharo.image save test

./vm.sh test update

./vm.sh test save t3-push

./vm.sh t3-push config http://somewhere.com ConfigurationOfBetaNineT3 --install=bleedingEdge --username=sven@beta9.be --password=---

I got the same crash with the update a couple of times and then it went through. Am I using the correct VM ? Does this VM work flawlessly on the CI servers ?

Any help would be appreciated.

Sven

Segmentation fault Thu Mar 7 13:08:57 2013

pharo VM version: 3.9-7 #1 Wed Mar 6 22:59:04 CET 2013 gcc 4.4.3 Built from: NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 6 2013 With: NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 6 2013 Revision: git://gitorious.org/cogvm/blessed.git Commit: 7473ca83a257cfb9e20eedc568f31f0437b9be39 Date: 2013-03-06 14:23:07 +0100 By: Esteban Lorenzano <estebanlm@gmail.com> Jenkins build #14532 Build host: Linux linux-ubuntu-10 2.6.32-38-server #83-Ubuntu SMP Wed Jan 4 11:26:59 UTC 2012 x86_64 GNU/Linux plugin path: /home/ubuntu/t3-push/vm/ [default: /home/ubuntu/t3-push/vm/]

C stack backtrace: /home/ubuntu/t3-push/vm/pharo[0x80a0d4c] /home/ubuntu/t3-push/vm/pharo[0x80a105d] [0xb78d640c] /home/ubuntu/t3-push/vm/pharo[0x807f9fd] /home/ubuntu/t3-push/vm/pharo[0x808011f] [0x7760d881] /home/ubuntu/t3-push/vm/pharo(interpret+0x78e)[0x8094fde] /home/ubuntu/t3-push/vm/pharo(main+0x2b3)[0x80a19f3] /lib/i386-linux-gnu/tls/i686/nosegneg/libc.so.6(__libc_start_main+0xe7)[0xb7736e37] /home/ubuntu/t3-push/vm/pharo[0x805ea81]

Smalltalk stack dump: 0xbfd22724 M MethodDictionary(Object)>becomeForward: 0x7948f890: a(n) MethodDictionary 0xbfd22750 M MethodDictionary>grow 0x7948f890: a(n) MethodDictionary 0xbfd22768 M MethodDictionary(HashedCollection)>fullCheck 0x7948f890: a(n) MethodDictionary 0xbfd22784 M MethodDictionary>at:put: 0x7948f890: a(n) MethodDictionary 0xbfd227a8 M Metaclass(Behavior)>basicAddSelector:withMethod: 0x7906818c: a(n) Metaclass 0xbfd227c8 M Metaclass(Behavior)>methodDictAddSelectorSilently:withMethod: 0x7906818c: a(n) Metaclass 0xbfd227e8 M Metaclass(Behavior)>addSelectorSilently:withMethod: 0x7906818c: a(n) Metaclass 0xbfd22808 M Metaclass(ClassDescription)>addSelectorSilently:withMethod: 0x7906818c: a(n) Metaclass 0xbfd22828 M MethodAddition>installMethod 0x79091124: a(n) MethodAddition 0xbfd22840 M [] in MCPackageLoader>basicLoad 0x7904c5c8: a(n) MCPackageLoader 0xbfd22860 M OrderedCollection>do: 0x7904c698: a(n) OrderedCollection 0xbfd2287c M [] in MCPackageLoader>basicLoad 0x7904c5c8: a(n) MCPackageLoader 0xbfd22898 M BlockClosure>on:do: 0x79068044: a(n) BlockClosure 0xbfd1d6f0 M [] in MCPackageLoader>basicLoad 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d710 M BlockClosure>ensure: 0x79067fc8: a(n) BlockClosure 0xbfd1d72c M MCPackageLoader>basicLoad 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d74c I [] in MCPackageLoader>loadWithNameLike: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d770 I [] in MCPackageLoader>useChangeSetNamed:during: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d790 M BlockClosure>ensure: 0x79067f04: a(n) BlockClosure 0xbfd1d7bc I MCPackageLoader>useChangeSetNamed:during: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d7e4 I MCPackageLoader>useNewChangeSetNamedLike:during: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d80c I MCPackageLoader>loadWithNameLike: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d834 I MCVersionLoader>loadWithNameLike: 0x7904c3a8: a(n) MCVersionLoader 0xbfd1d858 I MCVersionLoader>load 0x7904c3a8: a(n) MCVersionLoader 0xbfd1d878 I MetacelloGoferLoad(GoferLoad)>execute 0x7904c398: a(n) MetacelloGoferLoad 0xbfd1d8a0 I [] in MetacelloLoadingMCSpecLoader(MetacelloCommonMCSpecLoader)>loadPackageDirective:gofer: 0x7904be3c: a(n) MetacelloLoadingMCSpecLoader 0xbfd17708 I [] in MetacelloLoadingMCSpecLoader(MetacelloCommonMCSpecLoader)>loadPackageDirective:gofer: 0x7904be3c: a(n) MetacelloLoadingMCSpecLoader 0xbfd17724 M [] in MetacelloPharoPlatform>do:displaying: 0x77cdd608: a(n) MetacelloPharoPlatform 0xbfd17740 M BlockClosure>cull: 0x7904bf80: a(n) BlockClosure 0xbfd17760 M [] in Job>run 0x7904bf98: a(n) Job 0xbfd1777c M BlockClosure>on:do: 0x7904c0e8: a(n) BlockClosure 0xbfd177a0 M [] in Job>run 0x7904bf98: a(n) Job 0xbfd177c0 M BlockClosure>ensure: 0x7904c068: a(n) BlockClosure 0xbfd177e0 M Job>run 0x7904bf98: a(n) Job 0xbfd177f8 M NonInteractiveUIManager(UIManager)>displayProgress:from:to:during: 0x7850f674: a(n) NonInteractiveUIManager 0xbfd17820 M ByteString(String)>displayProgressFrom:to:during: 0x7904bef4: a(n) ByteString 0xbfd17844 M MetacelloPharoPlatform>do:displaying: 0x77cdd608: a(n) MetacelloPharoPlatform 0xbfd17870 I MetacelloLoadingMCSpecLoader(MetacelloCommonMCSpecLoader)>loadPackageDirective:gofer: 0x7904be3c: a(n) MetacelloLoadingMCSpecLoader 0xbfd17898 I MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadPackageDirective:gofer: 0x78b12464: a(n) MetacelloLinearLoadDirective 0xbfd1a6dc M MetacelloPackageLoadDirective>loadUsing:gofer: 0x78b15008: a(n) MetacelloPackageLoadDirective 0xbfd1a704 M [] in MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadLinearLoadDirective:gofer: 0x78b03ee0: a(n) MetacelloLinearLoadDirective 0xbfd1a724 M OrderedCollection>do: 0x78b15020: a(n) OrderedCollection 0xbfd1a740 M MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadLinearLoadDirective:gofer: 0x78b03ee0: a(n) MetacelloLinearLoadDirective 0xbfd1a760 M MetacelloLinearLoadDirective>loadUsing:gofer: 0x78b12464: a(n) MetacelloLinearLoadDirective 0xbfd1a788 M [] in MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadLinearLoadDirective:gofer: 0x78859664: a(n) MetacelloLinearLoadDirective 0xbfd1a7a8 M OrderedCollection>do: 0x78b0434c: a(n) OrderedCollection 0xbfd1a7c4 M MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadLinearLoadDirective:gofer: 0x78859664: a(n) MetacelloLinearLoadDirective 0xbfd1a7e4 M MetacelloLinearLoadDirective>loadUsing:gofer: 0x78b03ee0: a(n) MetacelloLinearLoadDirective 0xbfd1a80c M [] in MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadLinearLoadDirective:gofer: 0x78859664: a(n) MetacelloLinearLoadDirective 0xbfd1a82c M OrderedCollection>do: 0x78859678: a(n) OrderedCollection 0xbfd1a848 M MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadLinearLoadDirective:gofer: 0x78859664: a(n) MetacelloLinearLoadDirective 0xbfd1a870 I MetacelloLinearLoadDirective>loadUsing:gofer: 0x78859664: a(n) MetacelloLinearLoadDirective 0xbfd1a89c I MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadWithPolicy: 0x78859664: a(n) MetacelloLinearLoadDirective 0xbfd196ec I MetacelloLoaderPolicy>load 0x78de1b68: a(n) MetacelloLoaderPolicy 0xbfd1970c I MetacelloFetchingMCSpecLoader>doLoad 0x78859118: a(n) MetacelloFetchingMCSpecLoader 0xbfd19730 I [] in MetacelloMCVersion>doLoadRequiredFromArray: 0x78857380: a(n) MetacelloMCVersion 0xbfd1974c M [] in MetacelloPharoPlatform>do:displaying: 0x77cdd608: a(n) MetacelloPharoPlatform 0xbfd19768 M BlockClosure>cull: 0x78de19d8: a(n) BlockClosure 0xbfd19788 M [] in Job>run 0x78de19f0: a(n) Job 0xbfd197a4 M BlockClosure>on:do: 0x78de1b40: a(n) BlockClosure 0xbfd197c8 M [] in Job>run 0x78de19f0: a(n) Job 0xbfd197e8 M BlockClosure>ensure: 0x78de1ac0: a(n) BlockClosure 0xbfd19808 M Job>run 0x78de19f0: a(n) Job 0xbfd19820 M NonInteractiveUIManager(UIManager)>displayProgress:from:to:during: 0x7850f674: a(n) NonInteractiveUIManager 0xbfd19848 M ByteString(String)>displayProgressFrom:to:during: 0x78de1948: a(n) ByteString 0xbfd1986c M MetacelloPharoPlatform>do:displaying: 0x77cdd608: a(n) MetacelloPharoPlatform 0xbfd198a0 I [] in MetacelloMCVersion>doLoadRequiredFromArray: 0x78857380: a(n) MetacelloMCVersion 0x78858468 s BlockClosure>ensure: 0x788583dc s MetacelloMCVersion>doLoadRequiredFromArray: 0x78d7a318 s MetacelloMCVersion>load 0x78d7a374 s ConfigurationCommandLineHandler>installVersion: 0x78d7a3d0 s ConfigurationCommandLineHandler>installConfiguration 0x78d7a42c s ConfigurationCommandLineHandler>activate 0x78d7a488 s ConfigurationCommandLineHandler class(CommandLineHandler class)>activateWith: 0x78819c40 s DefaultCommandLineHandler>handleSubcommand 0x78819be4 s DefaultCommandLineHandler>handleArgument: 0x78819b88 s DefaultCommandLineHandler>activate 0x78d7908c s [] in DefaultCommandLineHandler class>startUp: 0x78d790e8 s BlockClosure>cull: 0x78d79144 s [] in SmalltalkImage>executeDeferredStartupActions: 0x7881a01c s BlockClosure>on:do: 0x78818170 s SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: 0x788180b0 s [] in SmalltalkImage>executeDeferredStartupActions: 0x78d791a0 s OrderedCollection>do: 0x78818010 s SmalltalkImage>executeDeferredStartupActions: 0x7859f04c s SmalltalkImage>startupImage:snapshotWorked: 0x7859e9e8 s SmalltalkImage>snapshot:andQuit: 0x7859ec10 s SmalltalkImage>saveImageInFileNamed: 0x7859ec6c s SmalltalkImage>saveAs: 0x78581170 s SaveCommandLineHandler>saveImage 0x7859ecc8 s SaveCommandLineHandler>activate 0x7859ed24 s SaveCommandLineHandler class(CommandLineHandler class)>activateWith: 0x7859ed80 s DefaultCommandLineHandler>handleSubcommand 0x78580dc0 s DefaultCommandLineHandler>handleArgument: 0x78580d64 s DefaultCommandLineHandler>activate 0x7859ea44 s [] in DefaultCommandLineHandler class>startUp: 0x7859eaa0 s BlockClosure>cull: 0x7859eafc s [] in SmalltalkImage>executeDeferredStartupActions: 0x7859eb58 s BlockClosure>on:do: 0x7857f3f4 s SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: 0x7857f334 s [] in SmalltalkImage>executeDeferredStartupActions: 0x7859ebb4 s OrderedCollection>do: 0x7857f294 s SmalltalkImage>executeDeferredStartupActions: 0x7857e4f0 s SmalltalkImage>startupImage:snapshotWorked: 0x7857e1c8 s SmalltalkImage>snapshot:andQuit: 0x7857e394 s LoadUpdatesCommandLineHandler>activate 0x7857e3f0 s LoadUpdatesCommandLineHandler class(CommandLineHandler class)>activateWith: 0x7857e44c s DefaultCommandLineHandler>handleSubcommand 0x7853a5d8 s DefaultCommandLineHandler>handleArgument: 0x7853a57c s DefaultCommandLineHandler>activate 0x7857e224 s [] in DefaultCommandLineHandler class>startUp: 0x7857e280 s BlockClosure>cull: 0x7857e2dc s [] in SmalltalkImage>executeDeferredStartupActions: 0x7853ad10 s BlockClosure>on:do: 0x78539480 s SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: 0x785393c0 s [] in SmalltalkImage>executeDeferredStartupActions: 0x7857e338 s OrderedCollection>do: 0x78538af4 s SmalltalkImage>executeDeferredStartupActions: 0x78537ea8 s SmalltalkImage>startupImage:snapshotWorked: 0x78537904 s SmalltalkImage>snapshot:andQuit: 0x78537b2c s SmalltalkImage>saveImageInFileNamed: 0x78537b88 s SmalltalkImage>saveAs: 0x78537610 s SaveCommandLineHandler>saveImage 0x78537be4 s SaveCommandLineHandler>activate 0x78537c40 s SaveCommandLineHandler class(CommandLineHandler class)>activateWith: 0x78537c9c s DefaultCommandLineHandler>handleSubcommand 0x78537260 s DefaultCommandLineHandler>handleArgument: 0x78537204 s DefaultCommandLineHandler>activate 0x78537960 s [] in DefaultCommandLineHandler class>startUp: 0x785379bc s BlockClosure>cull: 0x78537a18 s [] in SmalltalkImage>executeDeferredStartupActions: 0x78537a74 s BlockClosure>on:do: 0x78536100 s SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: 0x78536040 s [] in SmalltalkImage>executeDeferredStartupActions: 0x78537ad0 s OrderedCollection>do: 0x78535774 s SmalltalkImage>executeDeferredStartupActions: 0x78535254 s SmalltalkImage>startupImage:snapshotWorked: 0x78534c54 s SmalltalkImage>snapshot:andQuit: 0x78534cb0 s SmalltalkImage>saveImageInFileNamed: 0x78534d0c s SmalltalkImage>saveAs: 0x78534924 s SaveCommandLineHandler>saveImage 0x78534d68 s SaveCommandLineHandler>activate 0x78534dc4 s SaveCommandLineHandler class(CommandLineHandler class)>activateWith: 0x78534e20 s DefaultCommandLineHandler>handleSubcommand 0x78534e7c s DefaultCommandLineHandler>handleArgument: 0x78534574 s DefaultCommandLineHandler>activate 0x78534ed8 s [] in DefaultCommandLineHandler class>startUp: 0x78534f34 s BlockClosure>cull: 0x78534f90 s [] in SmalltalkImage>executeDeferredStartupActions: 0x78534fec s BlockClosure>on:do: 0x78533468 s SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: 0x785333a8 s [] in SmalltalkImage>executeDeferredStartupActions: 0x78535048 s OrderedCollection>do: 0x78532adc s SmalltalkImage>executeDeferredStartupActions: 0x785325d0 s SmalltalkImage>startupImage:snapshotWorked: 0x78532254 s SmalltalkImage>snapshot:andQuit: 0x785322b0 s LoadUpdatesCommandLineHandler>activate 0x7853230c s LoadUpdatesCommandLineHandler class(CommandLineHandler class)>activateWith: 0x78532368 s DefaultCommandLineHandler>handleSubcommand 0x785323c4 s DefaultCommandLineHandler>handleArgument: 0x7852c3d0 s DefaultCommandLineHandler>activate 0x78532420 s [] in DefaultCommandLineHandler class>startUp: 0x7853247c s BlockClosure>cull: 0x785324d8 s [] in SmalltalkImage>executeDeferredStartupActions: 0x7852ca20 s BlockClosure>on:do: 0x7852aa7c s SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: 0x7852a9bc s [] in SmalltalkImage>executeDeferredStartupActions: 0x78532534 s OrderedCollection>do: 0x7852a948 s SmalltalkImage>executeDeferredStartupActions: 0x7852a600 s SmalltalkImage>startupImage:snapshotWorked: 0x7852a000 s SmalltalkImage>snapshot:andQuit: 0x7852a05c s SmalltalkImage>saveImageInFileNamed: 0x7852a0b8 s SmalltalkImage>saveAs: 0x78529cd8 s SaveCommandLineHandler>saveImage 0x7852a114 s SaveCommandLineHandler>activate 0x7852a170 s SaveCommandLineHandler class(CommandLineHandler class)>activateWith: 0x7852a1cc s DefaultCommandLineHandler>handleSubcommand 0x7852a228 s DefaultCommandLineHandler>handleArgument: 0x78529928 s DefaultCommandLineHandler>activate 0x7852a284 s [] in DefaultCommandLineHandler class>startUp: 0x7852a2e0 s BlockClosure>cull: 0x7852a33c s [] in SmalltalkImage>executeDeferredStartupActions: 0x7852a398 s BlockClosure>on:do: 0x78527fc4 s SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: 0x78527f04 s [] in SmalltalkImage>executeDeferredStartupActions: 0x7852a3f4 s OrderedCollection>do: 0x78527e90 s SmalltalkImage>executeDeferredStartupActions: 0x78527a04 s SmalltalkImage>startupImage:snapshotWorked: 0x78527518 s SmalltalkImage>snapshot:andQuit: 0x78527574 s LoadUpdatesCommandLineHandler>activate 0x785275d0 s LoadUpdatesCommandLineHandler class(CommandLineHandler class)>activateWith: 0x7852762c s DefaultCommandLineHandler>handleSubcommand 0x78527688 s DefaultCommandLineHandler>handleArgument: 0x7852700c s DefaultCommandLineHandler>activate 0x785276e4 s [] in DefaultCommandLineHandler class>startUp: 0x78527740 s BlockClosure>cull: 0x7852779c s [] in SmalltalkImage>executeDeferredStartupActions: 0x785273b8 s BlockClosure>on:do: 0x785256b8 s SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: 0x785255f8 s [] in SmalltalkImage>executeDeferredStartupActions: 0x785277f8 s OrderedCollection>do: 0x78525584 s SmalltalkImage>executeDeferredStartupActions: 0x78525154 s SmalltalkImage>startupImage:snapshotWorked: 0x78524cc4 s SmalltalkImage>snapshot:andQuit: 0x78524d20 s SmalltalkImage>saveImageInFileNamed: 0x78524d7c s SmalltalkImage>saveAs: 0x78524ad0 s SaveCommandLineHandler>saveImage 0x78524dd8 s SaveCommandLineHandler>activate 0x78524e34 s SaveCommandLineHandler class(CommandLineHandler class)>activateWith: 0x78524e90 s DefaultCommandLineHandler>handleSubcommand 0x78524eec s DefaultCommandLineHandler>handleArgument: 0x78524720 s DefaultCommandLineHandler>activate 0x78524f48 s [] in DefaultCommandLineHandler class>startUp: 0x78524fa4 s BlockClosure>cull: 0x78525000 s [] in SmalltalkImage>executeDeferredStartupActions: 0x7852505c s BlockClosure>on:do: 0x78522dbc s SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: 0x78522cfc s [] in SmalltalkImage>executeDeferredStartupActions: 0x785250b8 s OrderedCollection>do: 0x78522c88 s SmalltalkImage>executeDeferredStartupActions: 0x78522960 s SmalltalkImage>startupImage:snapshotWorked: 0x785225e4 s SmalltalkImage>snapshot:andQuit: 0x78522640 s LoadUpdatesCommandLineHandler>activate 0x7852269c s LoadUpdatesCommandLineHandler class(CommandLineHandler class)>activateWith: 0x785226f8 s DefaultCommandLineHandler>handleSubcommand 0x78522754 s DefaultCommandLineHandler>handleArgument: 0x7851f5d0 s DefaultCommandLineHandler>activate 0x785227b0 s [] in DefaultCommandLineHandler class>startUp: 0x7852280c s BlockClosure>cull: 0x78522868 s [] in SmalltalkImage>executeDeferredStartupActions: 0x7851fc20 s BlockClosure>on:do: 0x7851dc7c s SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: 0x7851dbbc s [] in SmalltalkImage>executeDeferredStartupActions: 0x785228c4 s OrderedCollection>do: 0x7851db48 s SmalltalkImage>executeDeferredStartupActions: 0x7851d87c s SmalltalkImage>startupImage:snapshotWorked: 0x7851d27c s SmalltalkImage>snapshot:andQuit: 0x7851d2d8 s SmalltalkImage>saveImageInFileNamed: 0x7851d334 s SmalltalkImage>saveAs: 0x7851cf84 s SaveCommandLineHandler>saveImage 0x7851d390 s SaveCommandLineHandler>activate 0x7851d3ec s SaveCommandLineHandler class(CommandLineHandler class)>activateWith: 0x7851d448 s DefaultCommandLineHandler>handleSubcommand 0x7851d4a4 s DefaultCommandLineHandler>handleArgument: 0x7851cbd4 s DefaultCommandLineHandler>activate 0x7851d500 s [] in DefaultCommandLineHandler class>startUp: 0x7851d55c s BlockClosure>cull: 0x7851d5b8 s [] in SmalltalkImage>executeDeferredStartupActions: 0x7851d614 s BlockClosure>on:do: 0x7851b270 s SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: 0x7851b1b0 s [] in SmalltalkImage>executeDeferredStartupActions: 0x7851d670 s OrderedCollection>do: 0x7851b13c s SmalltalkImage>executeDeferredStartupActions: 0x7851acb0 s SmalltalkImage>startupImage:snapshotWorked: 0x7851a934 s SmalltalkImage>snapshot:andQuit: 0x7851a990 s LoadUpdatesCommandLineHandler>activate 0x7851a9ec s LoadUpdatesCommandLineHandler class(CommandLineHandler class)>activateWith: 0x7851aa48 s DefaultCommandLineHandler>handleSubcommand 0x7851aaa4 s DefaultCommandLineHandler>handleArgument: 0x78516470 s DefaultCommandLineHandler>activate 0x7851ab00 s [] in DefaultCommandLineHandler class>startUp: 0x7851ab5c s BlockClosure>cull: 0x7851abb8 s [] in SmalltalkImage>executeDeferredStartupActions: 0x78516ad4 s BlockClosure>on:do: 0x78514b1c s SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: 0x78514a5c s [] in SmalltalkImage>executeDeferredStartupActions: 0x7851ac14 s OrderedCollection>do: 0x785149e8 s SmalltalkImage>executeDeferredStartupActions: 0x7851470c s SmalltalkImage>startupImage:snapshotWorked: 0x7851410c s SmalltalkImage>snapshot:andQuit: 0x78514168 s SmalltalkImage>saveImageInFileNamed: 0x785141c4 s SmalltalkImage>saveAs: 0x78513e14 s SaveCommandLineHandler>saveImage 0x78514220 s SaveCommandLineHandler>activate 0x7851427c s SaveCommandLineHandler class(CommandLineHandler class)>activateWith: 0x785142d8 s DefaultCommandLineHandler>handleSubcommand 0x78514334 s DefaultCommandLineHandler>handleArgument: 0x78513a64 s DefaultCommandLineHandler>activate 0x78514390 s [] in DefaultCommandLineHandler class>startUp: 0x785143ec s BlockClosure>cull: 0x78514448 s [] in SmalltalkImage>executeDeferredStartupActions: 0x785144a4 s BlockClosure>on:do: 0x78512100 s SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: 0x78512040 s [] in SmalltalkImage>executeDeferredStartupActions: 0x78514500 s OrderedCollection>do: 0x78511fcc s SmalltalkImage>executeDeferredStartupActions: 0x78511b40 s SmalltalkImage>startupImage:snapshotWorked: 0x78511654 s SmalltalkImage>snapshot:andQuit: 0x785116b0 s LoadUpdatesCommandLineHandler>activate 0x7851170c s LoadUpdatesCommandLineHandler class(CommandLineHandler class)>activateWith: 0x78511768 s DefaultCommandLineHandler>handleSubcommand 0x785117c4 s DefaultCommandLineHandler>handleArgument: 0x78511148 s DefaultCommandLineHandler>activate 0x78511820 s [] in DefaultCommandLineHandler class>startUp: 0x7851187c s BlockClosure>cull: 0x785118d8 s [] in SmalltalkImage>executeDeferredStartupActions: 0x785114f4 s BlockClosure>on:do: 0x7850f7f4 s SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: 0x7850f734 s [] in SmalltalkImage>executeDeferredStartupActions: 0x78511934 s OrderedCollection>do: 0x7850f6c0 s SmalltalkImage>executeDeferredStartupActions: 0x7850f274 s SmalltalkImage>startupImage:snapshotWorked: 0x7850e880 s SmalltalkImage>snapshot:andQuit: 0x7850f17c s [] in WorldState class>saveAndQuit 0x7850f1d8 s BlockClosure>ensure: 0x784bfd7c s CursorWithMask(Cursor)>showWhile: 0x784bfd10 s WorldState class>saveAndQuit 0x784bfcb4 s [] in ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: 0x7850eef8 s BlockClosure>ensure: 0x784bfc44 s CursorWithMask(Cursor)>showWhile: 0x784bfbd4 s ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: 0x7850ef54 s ToggleMenuItemMorph(MenuItemMorph)>mouseUp: 0x7850efb0 s ToggleMenuItemMorph(MenuItemMorph)>handleMouseUp: 0x7850f00c s MouseButtonEvent>sentTo: 0x7850f068 s ToggleMenuItemMorph(Morph)>handleEvent: 0x7850f0c4 s MorphicEventDispatcher>dispatchDefault:with: 0x7850f120 s MorphicEventDispatcher>dispatchEvent:with: 0x784beee4 s ToggleMenuItemMorph(Morph)>processEvent:using: 0x784bee5c s MorphicEventDispatcher>dispatchDefault:with: 0x7850ec74 s MorphicEventDispatcher>dispatchEvent:with: 0x7850ecd0 s MenuMorph(Morph)>processEvent:using: 0x7850ed2c s MenuMorph(Morph)>processEvent: 0x7850ed88 s MenuMorph>handleFocusEvent: 0x7850ede4 s [] in HandMorph>sendFocusEvent:to:clear: 0x7850ee40 s [] in PasteUpMorph>becomeActiveDuring: 0x7850ee9c s BlockClosure>on:do: 0x784bed94 s PasteUpMorph>becomeActiveDuring: 0x784bed1c s HandMorph>sendFocusEvent:to:clear: 0x7850e8dc s HandMorph>sendEvent:focus:clear: 0x784beca8 s HandMorph>sendMouseEvent: 0x7850e938 s HandMorph>handleEvent: 0x7850e994 s HandMorph>processEvents 0x7850e9f0 s [] in WorldState>doOneCycleNowFor: 0x7850ea4c s Array(SequenceableCollection)>do: 0x7850eaa8 s WorldState>handsDo: 0x784beb30 s WorldState>doOneCycleNowFor: 0x7850eb04 s WorldState>doOneCycleFor: 0x7850eb60 s PasteUpMorph>doOneCycle 0x77b37118 s [] in MorphicUIManager>? 0x77b37094 s [] in BlockClosure>?

Most recent primitives objectAt:put: flushCache instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class basicAt:put: at:put: objectAt: objectAt: objectAt: objectAt: objectAt:put: objectAt: objectAt: objectAt: objectAt:put: flushCache instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: basicAt:put: at:put: objectAt: objectAt: objectAt: objectAt: objectAt:put: objectAt: objectAt: objectAt: objectAt:put: flushCache flushCache instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class basicAt:put: at:put: objectAt: objectAt: objectAt: objectAt: objectAt:put: objectAt: objectAt: objectAt: objectAt:put: flushCache instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class basicAt:put: at:put: objectAt: objectAt: objectAt: objectAt: objectAt:put: objectAt: objectAt: objectAt: objectAt:put: flushCache instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class basicAt:put: at:put: objectAt: objectAt: objectAt: objectAt: objectAt:put: objectAt: objectAt: objectAt: objectAt:put: flushCache instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class basicAt:put: at:put: objectAt: objectAt: objectAt: objectAt: objectAt:put: objectAt: objectAt: objectAt: objectAt:put: flushCache instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class instVarsInclude: class basicAt:put: at:put: species basicNew: new: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: basicAt:put: at:put: new: at:put: new: at:put: elementsForwardIdentityTo:

stack page bytes 4096 available headroom 3300 minimum unused headroom 2484

(Segmentation fault)

vm version? On Mar 7, 2013, at 4:35 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

On 07 Mar 2013, at 15:31, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

I am still investigating, but it seems things changed in the Ubuntu universe regarding ia32-libs on 64 bit (it does no longer exist). Maybe that is a factor as well, I am not sure.

I just installed a fresh 64-bit Ubuntu 12.10 Desktop in VirtualBox and tried my build there.

sudo apt-get install ia32-libs

is like a virtual package now that installs :i386 versions of already installed libraries (or something like that).

Anyway, the VM worked but crashed when doing my build, again in #becomeForward:

So it looks like is related to 32/64 bit differences.

What kind of Linux machines are the build slaves in the CI infrastructure ?

Sven

-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

On 2013-03-07, at 16:58, Sven Van Caekenberghe <sven@stfx.eu> wrote:

I am getting crazy, it seems to be pretty random, sometimes it works, most of the time it doesn't.

On 07 Mar 2013, at 16:40, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

vm version?

On both 32 and 64 bit...

this is strange. since this week I changed the vm test build to run on multiple platforms. At least since today everything looks good again there: https://ci.inria.fr/pharo/view/VM/job/PharoVM-tests/

I was using ciPharoVMLatest on my production server because you told me so, that has indeed #14533 in the version. 3.9-7 #1 Thu Mar 7 14:32:07 CET 2013 gcc 4.4.3 NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 7 2013 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 7 2013 git://gitorious.org/cogvm/blessed.git Commit: 7473ca83a257cfb9e20eedc568f31f0437b9be39 Date: 2013-03-06 14:23:07 +0100 By: Esteban Lorenzano <estebanlm@gmail.com> Jenkins build #14533 Linux linux-ubuntu-10 2.6.32-38-server #83-Ubuntu SMP Wed Jan 4 11:26:59 UTC 2012 x86_64 GNU/Linux plugin path: /home/ubuntu/t3-push/vm/ [default: /home/ubuntu/t3-push/vm/] That was giving trouble as well (64-bit upgraded 12.04.2 LTS). On the VirtualBox tests is was initially using ciPharoVM, I just switched to Latest on both 32 and 64 bit. The 32 bit one succeeded, the 64 bit one failed at the same spot. I hope you can reproduce this ... On 07 Mar 2013, at 17:13, Esteban Lorenzano <estebanlm@gmail.com> wrote:

Sven, I think you do not have the last one... it should say "Jenkins build #14533" someplace there... That probably will not change anything, but I want to be sure :)

Esteban

On Mar 7, 2013, at 4:58 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

I am getting crazy, it seems to be pretty random, sometimes it works, most of the time it doesn't.

On 07 Mar 2013, at 16:40, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

vm version?

<Screen Shot 2013-03-07 at 16.56.50.png>

On both 32 and 64 bit...

...

On Mar 7, 2013, at 4:35 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

On 07 Mar 2013, at 15:31, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

I am still investigating, but it seems things changed in the Ubuntu universe regarding ia32-libs on 64 bit (it does no longer exist). Maybe that is a factor as well, I am not sure.

I just installed a fresh 64-bit Ubuntu 12.10 Desktop in VirtualBox and tried my build there.

sudo apt-get install ia32-libs

is like a virtual package now that installs :i386 versions of already installed libraries (or something like that).

Anyway, the VM worked but crashed when doing my build, again in #becomeForward:

So it looks like is related to 32/64 bit differences.

What kind of Linux machines are the build slaves in the CI infrastructure ?

Sven

-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

On 08 Mar 2013, at 11:16, Sven Van Caekenberghe <sven@stfx.eu> wrote:

But I have said this before: the wall clock time of loading a lot of code is actually close to unacceptable - I don't think it is the download or the compilation, but more all the dynamic stuff that happens after that. There should be a way to not do all those updates for each method and move the updates to one big batch update after the load - if that is possible.

To continue my rant (sorry ;-) about the problem with slow code loading. These are some benchmarks on the same machine: $ ./vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' 106532 $ ./stack/vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' 221708 So it takes like 3 minutes to recompile every method in the system. How in the hell can it take 40 minutes to load some code (with all packages already present in the package-cache (but then again the package-cache is only 3.5 Mb, which could be downloaded in seconds)) ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

On 8 March 2013 11:44, Esteban Lorenzano <estebanlm@gmail.com> wrote:

Hi Sven,

One of the problems we currently have is that all method installation execute a becomeForward:, which is of course not terrible cleaver... I tried using the squeak implementation of it and everything looks working (and it has a small optimization that can help).

When do you call #becomeForward:? Do you do it for each method? #becomeForward: costs the same to change 1 object as it does 1000. On my rubbish laptop that's 6ms per #becomeForward. If I recall correctly, it's only when you're becoming several thousand objects that it starts taking longer. So if you can batch-become - using myOldMethods elementsForwardIdentityTo: myNewMethods - per package, maybe that would help speed things up? frank

Can you trying the load by installing it?

CompiledMethod>>#setSourcePointer: srcPointer "We can't change the trailer of existing method, since it could have a completely different format. Therefore we need to generate a copy with new trailer, containing a srcPointer, and then #become it." | trailer copy start |

trailer := srcPointer = 0 ifTrue: [ "catch the common case of setting the source pointer to 0 when already 0" self sourcePointer = 0 ifTrue: [ ^ self ]. CompiledMethodTrailer empty ] ifFalse: [ CompiledMethodTrailer new sourcePointer: srcPointer ]. copy := self copyWithTrailerBytes: trailer.

"ar 3/31/2010: Be a bit more clever since #become: is slow. If the old and the new trailer have the same size, just replace it." (self trailer class == trailer class and:[ self size = copy size ]) ifTrue: [ start := self endPC + 1. self replaceFrom: start to: self size with: copy startingAt: start ] ifFalse: [ self becomeForward: copy ].

^self "will be copy if #become was needed"

this can help in the speed and also can help on the vm crash problem (even if it is a workaround)...

Esteban

On Mar 8, 2013, at 11:53 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

On 08 Mar 2013, at 11:16, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

But I have said this before: the wall clock time of loading a lot of code is actually close to unacceptable - I don't think it is the download or the compilation, but more all the dynamic stuff that happens after that. There should be a way to not do all those updates for each method and move the updates to one big batch update after the load - if that is possible.

To continue my rant (sorry ;-) about the problem with slow code loading.

These are some benchmarks on the same machine:

$ ./vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' 106532

$ ./stack/vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' 221708

So it takes like 3 minutes to recompile every method in the system.

How in the hell can it take 40 minutes to load some code (with all packages already present in the package-cache (but then again the package-cache is only 3.5 Mb, which could be downloaded in seconds)) ?

Sven

-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

included :) On Mar 8, 2013, at 2:52 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

Hi Esteban,

On 08 Mar 2013, at 12:44, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

Hi Sven,

One of the problems we currently have is that all method installation execute a becomeForward:, which is of course not terrible cleaver... I tried using the squeak implementation of it and everything looks working (and it has a small optimization that can help).

Can you trying the load by installing it?

CompiledMethod>>#setSourcePointer: srcPointer "We can't change the trailer of existing method, since it could have a completely different format. Therefore we need to generate a copy with new trailer, containing a srcPointer, and then #become it." | trailer copy start |

trailer := srcPointer = 0 ifTrue: [ "catch the common case of setting the source pointer to 0 when already 0" self sourcePointer = 0 ifTrue: [ ^ self ]. CompiledMethodTrailer empty ] ifFalse: [ CompiledMethodTrailer new sourcePointer: srcPointer ]. copy := self copyWithTrailerBytes: trailer.

"ar 3/31/2010: Be a bit more clever since #become: is slow. If the old and the new trailer have the same size, just replace it." (self trailer class == trailer class and:[ self size = copy size ]) ifTrue: [ start := self endPC + 1. self replaceFrom: start to: self size with: copy startingAt: start ] ifFalse: [ self becomeForward: copy ].

^self "will be copy if #become was needed"

this can help in the speed and also can help on the vm crash problem (even if it is a workaround)...

Esteban

I used the following version

CompiledMethod>>#setSourcePointer: srcPointer "We can't change the trailer of existing method, since it could have completely different format. Therefore we need to generate a copy with new trailer, containing scrPointer, and then become it."

| trailer copy | trailer := CompiledMethodTrailer new sourcePointer: srcPointer. copy := self copyWithTrailerBytes: trailer. "If possible do a replace in place as an optimization" (self trailer class == trailer class and: [ self size = copy size ]) ifTrue: [ | start | start := self endPC + 1. self replaceFrom: start to: self size with: copy startingAt: start ] ifFalse: [ self becomeForward: copy ]. ^ self

And it worked fine. My build completed successfully (1 try only). But it took about as long as before (10 minutes using a Cog based VM).

Thanks again for the suggestion, I think we should incorporate that change, no ?

The class test is ugly and most probably not necessary in the current image, I would say.

Sven

...

On Mar 8, 2013, at 11:53 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

On 08 Mar 2013, at 11:16, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

But I have said this before: the wall clock time of loading a lot of code is actually close to unacceptable - I don't think it is the download or the compilation, but more all the dynamic stuff that happens after that. There should be a way to not do all those updates for each method and move the updates to one big batch update after the load - if that is possible.

To continue my rant (sorry ;-) about the problem with slow code loading.

These are some benchmarks on the same machine:

$ ./vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' 106532

$ ./stack/vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' 221708

So it takes like 3 minutes to recompile every method in the system.

How in the hell can it take 40 minutes to load some code (with all packages already present in the package-cache (but then again the package-cache is only 3.5 Mb, which could be downloaded in seconds)) ?

Sven

-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

On 8 March 2013 15:58, Sven Van Caekenberghe <sven@stfx.eu> wrote:

Thanks.

But my 2nd and 3rd runs crashed, both at

Smalltalk stack dump: 0xbf9c4c18 M MethodDictionary(Object)>becomeForward: 0x79299080: a(n) MethodDictionary 0xbf9c4c44 M MethodDictionary>grow 0x79299080: a(n) MethodDictionary 0xbf9c4c5c M MethodDictionary(HashedCollection)>fullCheck 0x79299080: a(n) MethodDictionary 0xbf9c4c78 M MethodDictionary>at:put: 0x79299080: a(n) MethodDictionary

so it is still becomeForward: but while growing a MethodDictionary, which is a pretty basic operation I guess.

this is one more explanation why things so slow when you installing new stuff because when you just recompiling existing methods, all methods are going into very same dictionary and it never grows.. but imagine that you creating a fresh class, and then one by one , adding new methods to it (and having like 100 methods per class) a default capacity for method dictionary is 24 methods: new "Create a new instance with 32 slots, which can hold at most 24 methods before growing is necessary." ^self newForCapacity: 32 so , if your classes have more, it will grow and use become.. trashing the performace :) btw, i wonder why MethodDictionary is variable sized.. it could hold keys and values as pairs in its array slot, without need to do #become on grow (just replacing array with new one)...

On 08 Mar 2013, at 15:46, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

included :)

On Mar 8, 2013, at 2:52 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

Hi Esteban,

On 08 Mar 2013, at 12:44, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

Hi Sven,

One of the problems we currently have is that all method installation execute a becomeForward:, which is of course not terrible cleaver... I tried using the squeak implementation of it and everything looks working (and it has a small optimization that can help).

Can you trying the load by installing it?

CompiledMethod>>#setSourcePointer: srcPointer "We can't change the trailer of existing method, since it could have a completely different format. Therefore we need to generate a copy with new trailer, containing a srcPointer, and then #become it." | trailer copy start |

trailer := srcPointer = 0 ifTrue: [ "catch the common case of setting the source pointer to 0 when already 0" self sourcePointer = 0 ifTrue: [ ^ self ]. CompiledMethodTrailer empty ] ifFalse: [ CompiledMethodTrailer new sourcePointer: srcPointer ]. copy := self copyWithTrailerBytes: trailer.

"ar 3/31/2010: Be a bit more clever since #become: is slow. If the old and the new trailer have the same size, just replace it." (self trailer class == trailer class and:[ self size = copy size ]) ifTrue: [ start := self endPC + 1. self replaceFrom: start to: self size with: copy startingAt: start ] ifFalse: [ self becomeForward: copy ].

^self "will be copy if #become was needed"

this can help in the speed and also can help on the vm crash problem (even if it is a workaround)...

Esteban

I used the following version

CompiledMethod>>#setSourcePointer: srcPointer "We can't change the trailer of existing method, since it could have completely different format. Therefore we need to generate a copy with new trailer, containing scrPointer, and then become it."

| trailer copy | trailer := CompiledMethodTrailer new sourcePointer: srcPointer. copy := self copyWithTrailerBytes: trailer. "If possible do a replace in place as an optimization" (self trailer class == trailer class and: [ self size = copy size ]) ifTrue: [ | start | start := self endPC + 1. self replaceFrom: start to: self size with: copy startingAt: start ] ifFalse: [ self becomeForward: copy ]. ^ self

And it worked fine. My build completed successfully (1 try only). But it took about as long as before (10 minutes using a Cog based VM).

Thanks again for the suggestion, I think we should incorporate that change, no ?

The class test is ugly and most probably not necessary in the current image, I would say.

Sven

...

On Mar 8, 2013, at 11:53 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

On 08 Mar 2013, at 11:16, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

But I have said this before: the wall clock time of loading a lot of code is actually close to unacceptable - I don't think it is the download or the compilation, but more all the dynamic stuff that happens after that. There should be a way to not do all those updates for each method and move the updates to one big batch update after the load - if that is possible.

To continue my rant (sorry ;-) about the problem with slow code loading.

These are some benchmarks on the same machine:

$ ./vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' 106532

$ ./stack/vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' 221708

So it takes like 3 minutes to recompile every method in the system.

How in the hell can it take 40 minutes to load some code (with all packages already present in the package-cache (but then again the package-cache is only 3.5 Mb, which could be downloaded in seconds)) ?

Sven

-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

-- Best regards, Igor Stasenko.

yes, thanks to Eliot fixes, latest VMs are a lot more stable... but looks that the problem is still arising in certain weird situations :( On Mar 8, 2013, at 5:13 PM, Paul DeBruicker <pdebruic@gmail.com> wrote:

Does that happen when you use the VM from the top of the list here:

http://pharo.gforge.inria.fr/ci/vm/pharo/linux/

specifically: http://pharo.gforge.inria.fr/ci/vm/pharo/linux/pharo-linux-stable.zip

?

I haven't had the problem since switching to it when loading the config of Seaside 31 on Ubuntu 12.04

Sven Van Caekenberghe-2 wrote

...

Thanks.

But my 2nd and 3rd runs crashed, both at

Smalltalk stack dump: 0xbf9c4c18 M MethodDictionary(Object)>becomeForward: 0x79299080: a(n) MethodDictionary 0xbf9c4c44 M MethodDictionary>grow 0x79299080: a(n) MethodDictionary 0xbf9c4c5c M MethodDictionary(HashedCollection)>fullCheck 0x79299080: a(n) MethodDictionary 0xbf9c4c78 M MethodDictionary>at:put: 0x79299080: a(n) MethodDictionary

so it is still becomeForward: but while growing a MethodDictionary, which is a pretty basic operation I guess.

On 08 Mar 2013, at 15:46, Esteban Lorenzano <

...

estebanlm@

...

> wrote:

...

included :)

On Mar 8, 2013, at 2:52 PM, Sven Van Caekenberghe <

...

sven@

...

> wrote:

...

...

Hi Esteban,

On 08 Mar 2013, at 12:44, Esteban Lorenzano <

...

estebanlm@

...

> wrote:

...

...

...

Hi Sven,

One of the problems we currently have is that all method installation execute a becomeForward:, which is of course not terrible cleaver... I tried using the squeak implementation of it and everything looks working (and it has a small optimization that can help).

Can you trying the load by installing it?

CompiledMethod>>#setSourcePointer: srcPointer "We can't change the trailer of existing method, since it could have a completely different format. Therefore we need to generate a copy with new trailer, containing a srcPointer, and then #become it." | trailer copy start |

trailer := srcPointer = 0 ifTrue: [ "catch the common case of setting the source pointer to 0 when already 0" self sourcePointer = 0 ifTrue: [ ^ self ]. CompiledMethodTrailer empty ] ifFalse: [ CompiledMethodTrailer new sourcePointer: srcPointer ]. copy := self copyWithTrailerBytes: trailer.

"ar 3/31/2010: Be a bit more clever since #become: is slow. If the old and the new trailer have the same size, just replace it." (self trailer class == trailer class and:[ self size = copy size ]) ifTrue: [ start := self endPC + 1. self replaceFrom: start to: self size with: copy startingAt: start ] ifFalse: [ self becomeForward: copy ].

^self "will be copy if #become was needed"

this can help in the speed and also can help on the vm crash problem (even if it is a workaround)...

Esteban

I used the following version

CompiledMethod>>#setSourcePointer: srcPointer "We can't change the trailer of existing method, since it could have completely different format. Therefore we need to generate a copy with new trailer, containing scrPointer, and then become it."

| trailer copy | trailer := CompiledMethodTrailer new sourcePointer: srcPointer. copy := self copyWithTrailerBytes: trailer. "If possible do a replace in place as an optimization" (self trailer class == trailer class and: [ self size = copy size ]) ifTrue: [ | start | start := self endPC + 1. self replaceFrom: start to: self size with: copy startingAt: start ] ifFalse: [ self becomeForward: copy ]. ^ self

And it worked fine. My build completed successfully (1 try only). But it took about as long as before (10 minutes using a Cog based VM).

Thanks again for the suggestion, I think we should incorporate that change, no ?

The class test is ugly and most probably not necessary in the current image, I would say.

Sven

...

On Mar 8, 2013, at 11:53 AM, Sven Van Caekenberghe <

...

sven@

...

> wrote:

...

...

...

...

On 08 Mar 2013, at 11:16, Sven Van Caekenberghe <

...

sven@

...

> wrote:

...

...

...

...

...

But I have said this before: the wall clock time of loading a lot of code is actually close to unacceptable - I don't think it is the download or the compilation, but more all the dynamic stuff that happens after that. There should be a way to not do all those updates for each method and move the updates to one big batch update after the load - if that is possible.

To continue my rant (sorry ;-) about the problem with slow code loading.

These are some benchmarks on the same machine:

$ ./vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' 106532

$ ./stack/vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' 221708

So it takes like 3 minutes to recompile every method in the system.

How in the hell can it take 40 minutes to load some code (with all packages already present in the package-cache (but then again the package-cache is only 3.5 Mb, which could be downloaded in seconds)) ?

Sven

-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

-- View this message in context: http://forum.world.st/VM-Crashes-tp4675526p4675784.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

On 08 Mar 2013, at 13:09, Camillo Bruni <camillobruni@gmail.com> wrote:

On 2013-03-08, at 11:53, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

On 08 Mar 2013, at 11:16, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

But I have said this before: the wall clock time of loading a lot of code is actually close to unacceptable - I don't think it is the download or the compilation, but more all the dynamic stuff that happens after that. There should be a way to not do all those updates for each method and move the updates to one big batch update after the load - if that is possible.

To continue my rant (sorry ;-) about the problem with slow code loading.

These are some benchmarks on the same machine:

$ ./vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' 106532

$ ./stack/vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' 221708

So it takes like 3 minutes to recompile every method in the system.

How in the hell can it take 40 minutes to load some code (with all packages already present in the package-cache (but then again the package-cache is only 3.5 Mb, which could be downloaded in seconds)) ?

I with you on this one! :D I always wondered what Metacello and Compiler do there! :D

Well, open the Time Profiler and load your favourite Config. You'll have a hard time finding the actual time slice of the compiler. As far as I could see in my run it was less than 1% ! All the rest MC, Gofer, RPackage and SystemAnnouncement stuff, even completion stuff. Quite a challenge to optimize if you ask me. Sven

We will have to address this! We are getting there :) Stef

...

...

...

But I have said this before: the wall clock time of loading a lot of code is actually close to unacceptable - I don't think it is the download or the compilation, but more all the dynamic stuff that happens after that. There should be a way to not do all those updates for each method and move the updates to one big batch update after the load - if that is possible.

To continue my rant (sorry ;-) about the problem with slow code loading.

These are some benchmarks on the same machine:

$ ./vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' 106532

$ ./stack/vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' 221708

So it takes like 3 minutes to recompile every method in the system.

How in the hell can it take 40 minutes to load some code (with all packages already present in the package-cache (but then again the package-cache is only 3.5 Mb, which could be downloaded in seconds)) ?

I with you on this one! :D I always wondered what Metacello and Compiler do there! :D

Well, open the Time Profiler and load your favourite Config. You'll have a hard time finding the actual time slice of the compiler. As far as I could see in my run it was less than 1% ! All the rest MC, Gofer, RPackage and SystemAnnouncement stuff, even completion stuff.

Quite a challenge to optimize if you ask me.

Sven

EstebanLM wrote

Sven, I think you do not have the last one... it should say "Jenkins build #14533" someplace there... That probably will not change anything, but I want to be sure :)

Esteban

I'm having the same problem (intermittent crashes when loading code into Pharo2 with #becomeForward:). I'm loading Seaside3.1 using an image and VM I downloaded today with this script: curl http://pharo.gforge.inria.fr/ci/script/ciPharo20CogVM.sh | bash I've attached the crash.dmp crash.dmp <http://forum.world.st/file/n4675599/crash.dmp> It seems to me that the script ciPharo20CogVM.sh may not be downloading the VM you intend it to. Is that possible? If I do ./vm.sh -version I get: paul@paul-laptop:~/pharo/p2$ ./vm.sh -version 3.9-7 #1 Wed Dec 12 16:08:04 CET 2012 gcc 4.6.3 CoInterpreter VMMaker-oscog-EstebanLorenzano.166 uuid: 5773fcb9-2982-4507-8a9e-4308ec33731e Dec 12 2012 StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.166 uuid: 5773fcb9-2982-4507-8a9e-4308ec33731e Dec 12 2012 git://gitorious.org/cogvm/blessed.git Commit: 452863bdfba2ba0b188e7b172e9bc597a2caa928 Date: 2012-12-07 16:49:46 +0100 By: Esteban Lorenzano <estebanlm@gmail.com> Jenkins build #5922 Linux pharo-linux64 3.2.0-31-generic #50-Ubuntu SMP Fri Sep 7 16:16:45 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux plugin path: /home/paul/pharo/p2/vm/ [default: /home/paul/pharo/p2/vm/] If I change to the vm directory and get a directory listing I get: paul@paul-laptop:~/pharo/p2/vm$ ls -latr total 39316 -rw-r--r-- 1 paul paul 16235372 Oct 19 2009 PharoV10.sources drwxrwxr-x 2 paul paul 4096 Sep 30 03:52 __MACOSX -rwxrwxr-x 1 paul paul 34420 Dec 12 07:07 libFT2Plugin.so -rwxrwxr-x 1 paul paul 34639 Dec 12 07:08 libSqueakFFIPrims.so -rwxrwxr-x 1 paul paul 71180 Dec 12 07:08 libB3DAcceleratorPlugin.so -rwxrwxr-x 1 paul paul 21929 Dec 12 07:08 libSqueakSSL.so -rwxrwxr-x 1 paul paul 12230 Dec 12 07:08 libInternetConfigPlugin.so -rwxrwxr-x 1 paul paul 14461 Dec 12 07:08 vm-display-null -rwxrwxr-x 1 paul paul 1300278 Dec 12 07:08 CogVM -rwxrwxr-x 1 paul paul 7773 Dec 12 07:08 vm-sound-null -rwxrwxr-x 1 paul paul 28640 Dec 12 07:08 vm-sound-ALSA -rwxrwxr-x 1 paul paul 121415 Dec 12 07:08 vm-display-X11 -rw-r--r-- 1 paul paul 22239552 Mar 4 06:14 PharoV20.sources drwxrwxr-x 3 paul paul 4096 Mar 7 06:58 . drwxrwxr-x 4 paul paul 4096 Mar 7 11:00 .. Where do I get the correct VM that should output the error messages Eliot mentions below? Thanks Paul -- View this message in context: http://forum.world.st/VM-Crashes-tp4675526p4675599.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sven Van Caekenberghe-2 wrote

I am trying to isolate it, but it seems to occur only with larger code loads. Seaside would of course make an excellent example.

Paul,

Could we use your config using the modern pharo invocation, like

./vm.sh zinc config http://mc.stfx.eu/ZincHTTPComponents ConfigurationOfZincHTTPComponents --install=bleedingEdge --group=SSO

?

Dunno. Looks reasonable. I'll send you a zip of the mcz's offlist OK? -- View this message in context: http://forum.world.st/VM-Crashes-tp4675526p4675605.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sven Van Caekenberghe-2 wrote

...

Dunno. Looks reasonable. I'll send you a zip of the mcz's offlist OK?

I thought your config/code was public - no problem if that isn't so (yet).

Yeah it is. Or could/will be. I emailed them because I don't have commit rights to the Seaside repos on squeaksource (have never asked for them), the configs/packages havent been vetted by anyone yet, and didn't want to send a 300kb attachment to the whole list. As far as I know they work across all the platforms (ex gemstone), but I'm going to put them through here: travisci.org/pdebruic/ConfigurationOfSeaside30 before trying to get them adopted. Anyways, good luck with the VM crashes -- View this message in context: http://forum.world.st/VM-Crashes-tp4675526p4675622.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

On 8 March 2013 00:14, Ben Coman <btc@openinworld.com> wrote:

Just to remove doubt, you might try http://www.memtest.org/

with faulty memory you will get a lots of kernel panics at random times running random software not just Pharo VM :)

Sven Van Caekenberghe wrote:

...

I am trying to isolate it, but it seems to occur only with larger code loads. Seaside would of course make an excellent example.

Paul,

Could we use your config using the modern pharo invocation, like

./vm.sh zinc config http://mc.stfx.eu/ZincHTTPComponents ConfigurationOfZincHTTPComponents --install=bleedingEdge --group=SSO

?

Here is the full help

./vm.sh zinc config --help Usage: config [--help] <repository url> [<configuration>] [--install[=<version>]] [--group=<group>] [--username=<username>] [--password=<password>] --help show this help message <repository url> A Monticello repository name <configuration> A valid Metacello Configuration name <version> A valid version for the given configuration <group> A valid Metacello group name <username> An optional username to access the configuration's repository <password> An optional password to access the configuration's repository

Examples: # display this help message $PharoVM My.image config

# list all configurations of a repository $PharoVM My.image config $MC_REPOS_URL

# list all the available versions of a confgurtation $PharoVM My.image config $MC_REPOS_URL ConfigurationOfFoo

# install the stable version $PharoVM My.image config $MC_REPOS_URL ConfigurationOfFoo --install

#install a specific version '1.5' $PharoVM My.image config $MC_REPOS_URL ConfigurationOfFoo --install=1.5

#install a specific version '1.5' and only a specific group 'Tests' $PharoVM My.image config $MC_REPOS_URL ConfigurationOfFoo --install=1.5 --group=Tests

Sven

On 07 Mar 2013, at 20:09, Paul DeBruicker <pdebruic@gmail.com> wrote:

...

EstebanLM wrote

...

Sven, I think you do not have the last one... it should say "Jenkins build #14533" someplace there... That probably will not change anything, but I want to be sure :)

Esteban

I'm having the same problem (intermittent crashes when loading code into Pharo2 with #becomeForward:). I'm loading Seaside3.1 using an image and VM I downloaded today with this script:

curl http://pharo.gforge.inria.fr/ci/script/ciPharo20CogVM.sh | bash

I've attached the crash.dmp crash.dmp <http://forum.world.st/file/n4675599/crash.dmp> It seems to me that the script ciPharo20CogVM.sh may not be downloading the VM you intend it to. Is that possible? If I do ./vm.sh -version I get: paul@paul-laptop:~/pharo/p2$ ./vm.sh -version 3.9-7 #1 Wed Dec 12 16:08:04 CET 2012 gcc 4.6.3 CoInterpreter VMMaker-oscog-EstebanLorenzano.166 uuid: 5773fcb9-2982-4507-8a9e-4308ec33731e Dec 12 2012 StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.166 uuid: 5773fcb9-2982-4507-8a9e-4308ec33731e Dec 12 2012 git://gitorious.org/cogvm/blessed.git Commit: 452863bdfba2ba0b188e7b172e9bc597a2caa928 Date: 2012-12-07 16:49:46 +0100 By: Esteban Lorenzano <estebanlm@gmail.com> Jenkins build #5922 Linux pharo-linux64 3.2.0-31-generic #50-Ubuntu SMP Fri Sep 7 16:16:45 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux plugin path: /home/paul/pharo/p2/vm/ [default: /home/paul/pharo/p2/vm/]

If I change to the vm directory and get a directory listing I get:

paul@paul-laptop:~/pharo/p2/vm$ ls -latr total 39316 -rw-r--r-- 1 paul paul 16235372 Oct 19 2009 PharoV10.sources drwxrwxr-x 2 paul paul 4096 Sep 30 03:52 __MACOSX -rwxrwxr-x 1 paul paul 34420 Dec 12 07:07 libFT2Plugin.so -rwxrwxr-x 1 paul paul 34639 Dec 12 07:08 libSqueakFFIPrims.so -rwxrwxr-x 1 paul paul 71180 Dec 12 07:08 libB3DAcceleratorPlugin.so -rwxrwxr-x 1 paul paul 21929 Dec 12 07:08 libSqueakSSL.so -rwxrwxr-x 1 paul paul 12230 Dec 12 07:08 libInternetConfigPlugin.so -rwxrwxr-x 1 paul paul 14461 Dec 12 07:08 vm-display-null -rwxrwxr-x 1 paul paul 1300278 Dec 12 07:08 CogVM -rwxrwxr-x 1 paul paul 7773 Dec 12 07:08 vm-sound-null -rwxrwxr-x 1 paul paul 28640 Dec 12 07:08 vm-sound-ALSA -rwxrwxr-x 1 paul paul 121415 Dec 12 07:08 vm-display-X11 -rw-r--r-- 1 paul paul 22239552 Mar 4 06:14 PharoV20.sources drwxrwxr-x 3 paul paul 4096 Mar 7 06:58 . drwxrwxr-x 4 paul paul 4096 Mar 7 11:00 ..

Where do I get the correct VM that should output the error messages Eliot mentions below?

Thanks

Paul

-- View this message in context: http://forum.world.st/VM-Crashes-tp4675526p4675599.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

-- Best regards, Igor Stasenko.

Hi Eliot, On 07 Mar 2013, at 23:12, Eliot Miranda <eliot.miranda@gmail.com> wrote:

I seem to be talking to thin air. If you would use an up-to-date VM your crashes would disappear. This bug was fixed this last week. You are using a VM from December of last year. Of course if you don't want to fix your bug lease continue to ignore anything I might have to say.

I tried using your latest cog vm, but the Pharo 2.0 image side check complained: checkVMVersion "Display a warning if the VM is too old" | displayError | displayError := [ ^ self inform: 'Your VM is too old for this image. Please download the latest VM.' ]. [(VirtualMachine interpreterSourceDate > '2012-07-08+2:00' asDate) ifFalse: displayError ] on: Error do: [ :e| displayError value ]. I was unsure if this was a real problem or not ? Maybe it just fails to extract the date ? interpreterSourceDate "Return the date of changes given by `self interpreterSourceVersion`" | dateString parts | dateString := (self interpreterSourceVersion splitOn: 'Date: ') second. dateString first isDigit ifTrue: [ "most probably the date is in ISO 8601 Format" ^ dateString asDateAndTime ]. "Otherwise assume the old format: DDD MMM DD HH:MM:SS YYYY +TTTT ..." parts := dateString substrings first: 6. "create a more reasonable string.." dateString := String streamContents: [ :s | s nextPutAll: (parts at: 5 ); space; "year" nextPutAll: (parts at: 2 ); space; "month name" nextPutAll: (parts at: 3 ); space; "day of month" nextPutAll: (parts at: 4 ); space; "time" nextPutAll: (parts last); space "timezone"]. ^ dateString asDateAndTime Sven

On Thu, Mar 07, 2013 at 11:23:22PM +0100, Sven Van Caekenberghe wrote:

Hi Eliot,

On 07 Mar 2013, at 23:12, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

I seem to be talking to thin air. If you would use an up-to-date VM your crashes would disappear. This bug was fixed this last week. You are using a VM from December of last year. Of course if you don't want to fix your bug lease continue to ignore anything I might have to say.

I tried using your latest cog vm, but the Pharo 2.0 image side check complained:

checkVMVersion "Display a warning if the VM is too old" | displayError | displayError := [ ^ self inform: 'Your VM is too old for this image. Please download the latest VM.' ]. [(VirtualMachine interpreterSourceDate > '2012-07-08+2:00' asDate) ifFalse: displayError ] on: Error do: [ :e| displayError value ].

I was unsure if this was a real problem or not ?

This method in the image is completely wrong and misleading. The VM that was being used is clearly *not* out of date. If the intent is to give the user a message that says "please use only the latest Pharo VM", then it should say so. To check explicitly for a Pharo VM I would suggest adding a primitive or VM parameter that identifies the VM as Pharo-specific so the checkVMVersion can distinguish an out-of-date Pharo VM and provide an appropriate warning message. It is really not fair to ask Eliot to spend his time debugging "Cog problems" when the image is sending incorrect error messages. Dave

On 08 Mar 2013, at 09:45, Camillo Bruni <camillobruni@gmail.com> wrote:

On 2013-03-08, at 02:52, "David T. Lewis" <lewis@mail.msen.com> wrote:

...

On Thu, Mar 07, 2013 at 11:23:22PM +0100, Sven Van Caekenberghe wrote:

...

Hi Eliot,

On 07 Mar 2013, at 23:12, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

I seem to be talking to thin air. If you would use an up-to-date VM your crashes would disappear. This bug was fixed this last week. You are using a VM from December of last year. Of course if you don't want to fix your bug lease continue to ignore anything I might have to say.

I tried using your latest cog vm, but the Pharo 2.0 image side check complained:

checkVMVersion "Display a warning if the VM is too old" | displayError | displayError := [ ^ self inform: 'Your VM is too old for this image. Please download the latest VM.' ]. [(VirtualMachine interpreterSourceDate > '2012-07-08+2:00' asDate) ifFalse: displayError ] on: Error do: [ :e| displayError value ].

I was unsure if this was a real problem or not ?

This method in the image is completely wrong and misleading. The VM that was being used is clearly *not* out of date. If the intent is to give the user a message that says "please use only the latest Pharo VM", then it should say so.

Pharo ships with the PharoVM, hence the targeted audience will have an outdated PharoVM, we can make the message more explicit, but it IS an outdate VM no matter what.

Besides, we print the VM version date in a different format, which won't lead to a parsing error. If you run this on a VM not built by us you get a VM out of date.

...

To check explicitly for a Pharo VM I would suggest adding a primitive or VM parameter that identifies the VM as Pharo-specific so the checkVMVersion can distinguish an out-of-date Pharo VM and provide an appropriate warning message.

yes we could update the error message to inform that the user should download the latest PharoVM. But as I said before, Pharo is shipped with the branded PharoVM, to limit the confusion for newcomers. CogVM, NBCogCM, StackVM, SqueakVM and guess not what other names are simply not parseable by newcomers.

...

It is really not fair to ask Eliot to spend his time debugging "Cog problems" when the image is sending incorrect error messages.

well, he is free to adopt our additions we made to the FileSystem primitives and integrate NativeBoost.

Only if those are integrated I see reason to make this error message disappear on other VMs than ours. Otherwise not displaying the error message is misleading behavior as well FOR THE WHOLE COMMUNITY.

Thanks for the explanation, Camillo. The crux of the matter is the point about the FileSystem primitives and NativeBoost. The test itself is misleading as it only seems to check a date and then declares VM's too old. Maybe it should test for the primitives, if that is possible. Also the warning 'Too old' should be changed to 'Does not contain the necessary primitives to run Pharo' if I understand correctly. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Camillo Bruni-3 wrote

If it's too old, what do you do? you go and fetch a newer VM ;). So I would say the implied actions are ok, especially for newcomers, but there should be more details indeed.

Since Zinc is now included could the warning instead be a choice dialog that lets the user download either an appropriate VM for the image or an altogether more-up-to-date image+vm combo rather than just leaving the user to figure out how and where to find an appropriate VM? -- View this message in context: http://forum.world.st/VM-Crashes-tp4675526p4675781.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

On 8 March 2013 10:07, Sven Van Caekenberghe <sven@stfx.eu> wrote:

On 08 Mar 2013, at 09:45, Camillo Bruni <camillobruni@gmail.com> wrote:

...

On 2013-03-08, at 02:52, "David T. Lewis" <lewis@mail.msen.com> wrote:

...

On Thu, Mar 07, 2013 at 11:23:22PM +0100, Sven Van Caekenberghe wrote:

...

Hi Eliot,

On 07 Mar 2013, at 23:12, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

I seem to be talking to thin air. If you would use an up-to-date VM your crashes would disappear. This bug was fixed this last week. You are using a VM from December of last year. Of course if you don't want to fix your bug lease continue to ignore anything I might have to say.

I tried using your latest cog vm, but the Pharo 2.0 image side check complained:

checkVMVersion "Display a warning if the VM is too old" | displayError | displayError := [ ^ self inform: 'Your VM is too old for this image. Please download the latest VM.' ]. [(VirtualMachine interpreterSourceDate > '2012-07-08+2:00' asDate) ifFalse: displayError ] on: Error do: [ :e| displayError value ].

I was unsure if this was a real problem or not ?

This method in the image is completely wrong and misleading. The VM that was being used is clearly *not* out of date. If the intent is to give the user a message that says "please use only the latest Pharo VM", then it should say so.

Pharo ships with the PharoVM, hence the targeted audience will have an outdated PharoVM, we can make the message more explicit, but it IS an outdate VM no matter what.

Besides, we print the VM version date in a different format, which won't lead to a parsing error. If you run this on a VM not built by us you get a VM out of date.

...

To check explicitly for a Pharo VM I would suggest adding a primitive or VM parameter that identifies the VM as Pharo-specific so the checkVMVersion can distinguish an out-of-date Pharo VM and provide an appropriate warning message.

yes we could update the error message to inform that the user should download the latest PharoVM. But as I said before, Pharo is shipped with the branded PharoVM, to limit the confusion for newcomers. CogVM, NBCogCM, StackVM, SqueakVM and guess not what other names are simply not parseable by newcomers.

...

It is really not fair to ask Eliot to spend his time debugging "Cog problems" when the image is sending incorrect error messages.

well, he is free to adopt our additions we made to the FileSystem primitives and integrate NativeBoost.

Only if those are integrated I see reason to make this error message disappear on other VMs than ours. Otherwise not displaying the error message is misleading behavior as well FOR THE WHOLE COMMUNITY.

Thanks for the explanation, Camillo.

The crux of the matter is the point about the FileSystem primitives and NativeBoost. The test itself is misleading as it only seems to check a date and then declares VM's too old. Maybe it should test for the primitives, if that is possible.

Also the warning 'Too old' should be changed to 'Does not contain the necessary primitives to run Pharo' if I understand correctly.

hmm.. then your tests will define "today's old VM" but since things are moving, you have to throw this test away fairly soon.. to avoid that, i would check the version / VM release date.. but not some concrete feature, because at longer time scale it makes no sense. And to cover features, we have unit tests :)

Sven

-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

-- Best regards, Igor Stasenko.

On Fri, Mar 08, 2013 at 11:23:27AM +0100, stephane ducasse wrote:

On Mar 8, 2013, at 2:52 AM, David T. Lewis <lewis@mail.msen.com> wrote:

...

On Thu, Mar 07, 2013 at 11:23:22PM +0100, Sven Van Caekenberghe wrote:

...

Hi Eliot,

On 07 Mar 2013, at 23:12, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

I seem to be talking to thin air. If you would use an up-to-date VM your crashes would disappear. This bug was fixed this last week. You are using a VM from December of last year. Of course if you don't want to fix your bug lease continue to ignore anything I might have to say.

I tried using your latest cog vm, but the Pharo 2.0 image side check complained:

checkVMVersion "Display a warning if the VM is too old" | displayError | displayError := [ ^ self inform: 'Your VM is too old for this image. Please download the latest VM.' ]. [(VirtualMachine interpreterSourceDate > '2012-07-08+2:00' asDate) ifFalse: displayError ] on: Error do: [ :e| displayError value ].

I was unsure if this was a real problem or not ?

This method in the image is completely wrong and misleading. The VM that was being used is clearly *not* out of date. If the intent is to give the user a message that says "please use only the latest Pharo VM", then it should say so.

I do not understand why. I want to know that I'm not using a VM supporting fileplugin latest addition.

I was trying to suggest a more meaningful message for the use case of a user running Pharo on a non-Pharo VM. The message says to get a newer VM, which is wrong in that case. Yes I understand that I am not part of the target market. I am a person who is trying to maintain external packages for Squeak and Pharo. Sometimes I need to use another VM in order to do that, so I think it's a legitimate use case. Dave

...

To check explicitly for a Pharo VM I would suggest adding a primitive or VM parameter that identifies the VM as Pharo-specific so the checkVMVersion can distinguish an out-of-date Pharo VM and provide an appropriate warning message.

It is really not fair to ask Eliot to spend his time debugging "Cog problems" when the image is sending incorrect error messages.

Dave

I was trying to suggest a more meaningful message for the use case of a user running Pharo on a non-Pharo VM. The message says to get a newer VM, which is wrong in that case.

Ah that of course :)

Yes I understand that I am not part of the target market. I am a person who is trying to maintain external packages for Squeak and Pharo. Sometimes I need to use another VM in order to do that, so I think it's a legitimate use case.

Dave

On 07/03/13 15:58, Sven Van Caekenberghe wrote:

I am getting crazy, it seems to be pretty random, sometimes it works, most of the time it doesn't.

Well, if it sometimes happen and sometimes not and on other machines the same binary works like a charm, I would say this is due to a memory corruption - but you probably know that already :-) The crash in #becomeForward: is likely as it scans whole memory and sooner or later, it hit the corrupt object. So I think the #becomeForward: is probably not the bad guy here.

On 07 Mar 2013, at 16:40, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:

...

vm version?

On both 32 and 64 bit...

...

On Mar 7, 2013, at 4:35 PM, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote:

...

On 07 Mar 2013, at 15:31, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote:

...

I am still investigating, but it seems things changed in the Ubuntu universe regarding ia32-libs on 64 bit (it does no longer exist). Maybe that is a factor as well, I am not sure.

I just installed a fresh 64-bit Ubuntu 12.10 Desktop in VirtualBox and tried my build there.

sudo apt-get install ia32-libs

is like a virtual package now that installs :i386 versions of already installed libraries (or something like that).

Anyway, the VM worked but crashed when doing my build, again in #becomeForward:

So it looks like is related to 32/64 bit differences.

What kind of Linux machines are the build slaves in the CI infrastructure ?

Sven

-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

On 2013-03-07, at 16:35, Sven Van Caekenberghe <sven@stfx.eu> wrote:

On 07 Mar 2013, at 15:31, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

I am still investigating, but it seems things changed in the Ubuntu universe regarding ia32-libs on 64 bit (it does no longer exist). Maybe that is a factor as well, I am not sure.

I just installed a fresh 64-bit Ubuntu 12.10 Desktop in VirtualBox and tried my build there.

sudo apt-get install ia32-libs

is like a virtual package now that installs :i386 versions of already installed libraries (or something like that).

Anyway, the VM worked but crashed when doing my build, again in #becomeForward:

So it looks like is related to 32/64 bit differences.

What kind of Linux machines are the build slaves in the CI infrastructure ?

we used to build under ubuntu 12 and now I downgraded it to ubuntu LTS 10.04.4