Re: [Pharo-project] VM Crashes
On 2013-03-08, at 02:52, David T. Lewis le...@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.mira...@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.
Re: [Pharo-project] VM Crashes
On 08 Mar 2013, at 09:45, Camillo Bruni camillobr...@gmail.com wrote: On 2013-03-08, at 02:52, David T. Lewis le...@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.mira...@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
Re: [Pharo-project] VM Crashes
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. Well indeed we could check if the FS primitives return an array containing all information we need. The date itself might be a bit brittle, but since the other VMs don't have a parseable date it should fail there, mission accomplished, though with dubious tests, I agree ;) Also the warning 'Too old' should be changed to 'Does not contain the necessary primitives to run Pharo' if I understand correctly. 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.
Re: [Pharo-project] VM Crashes
On 8 March 2013 10:07, Sven Van Caekenberghe s...@stfx.eu wrote: On 08 Mar 2013, at 09:45, Camillo Bruni camillobr...@gmail.com wrote: On 2013-03-08, at 02:52, David T. Lewis le...@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.mira...@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.
Re: [Pharo-project] VM Crashes
On 07 Mar 2013, at 17:30, Sven Van Caekenberghe s...@stfx.eu wrote: I hope you can reproduce this ... Well, here is another datapoint. The bigger build that I was doing and that fails a lot with the reported crash.dmp worked twice and has not yet failed with the StackVM, although it takes a ridiculous long time (40 minutes). For the problem I saw, this VM is reliable: $ ./stack/vm.sh -version 3.9-7 #1 Mon Nov 19 19:12:44 CET 2012 gcc 4.1.2 StackInterpreter VMMaker-oscog-EstebanLorenzano.166 uuid: 5773fcb9-2982-4507-8a9e-4308ec33731e Nov 19 2012 git://gitorious.org/cogvm/blessed.git Commit: 40ac7e7bdec6fef0e934d2c019b86db996053912 Date: 2012-11-19 18:54:49 +0100 By: Mariano Martinez Peck marianop...@gmail.com Jenkins build #3 Linux pharo-build.lille.inria.fr 2.6.18-194.26.1.el5xen #1 SMP Tue Nov 9 14:13:46 EST 2010 i686 i686 i386 GNU/Linux plugin path: /home/ubuntu/t3-push/stack/vm/stack-linux-latest/ [default: /home/ubuntu/t3-push/stack/vm/stack-linux-latest/] I tried yesterday to come up with some public code to load to generate the problem, but I did not succeed yet. The build that I am doing is a Configuration that depends on a couple of other Configurations, it is not small, but I would not call it massive. Seaside is certainly bigger, and Moose is probably many times as large. 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. C++ is notoriously slow to compile because of all the static type checking and the amount of context that is needed to understand a piece of code. One of the main reasons to start Go was the slow build times, and Go remains statically typed. Smalltalk is dynamically typed and late bound in everything, surely it should be possible to make our code loading process faster. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Re: [Pharo-project] VM Crashes
On 08 Mar 2013, at 11:16, Sven Van Caekenberghe s...@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
Re: [Pharo-project] VM Crashes
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 On Mar 8, 2013, at 11:53 AM, Sven Van Caekenberghe s...@stfx.eu wrote: On 08 Mar 2013, at 11:16, Sven Van Caekenberghe s...@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
Re: [Pharo-project] VM Crashes
On 8 March 2013 11:44, Esteban Lorenzano esteba...@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 s...@stfx.eu wrote: On 08 Mar 2013, at 11:16, Sven Van Caekenberghe s...@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
Re: [Pharo-project] VM Crashes
On 2013-03-08, at 11:53, Sven Van Caekenberghe s...@stfx.eu wrote: On 08 Mar 2013, at 11:16, Sven Van Caekenberghe s...@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
Re: [Pharo-project] VM Crashes
On Mar 8, 2013, at 2:52 AM, David T. Lewis le...@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.mira...@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. 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
Re: [Pharo-project] VM Crashes
On Fri, Mar 08, 2013 at 11:23:27AM +0100, stephane ducasse wrote: On Mar 8, 2013, at 2:52 AM, David T. Lewis le...@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.mira...@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
Re: [Pharo-project] VM Crashes
Hi Esteban, On 08 Mar 2013, at 12:44, Esteban Lorenzano esteba...@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 s...@stfx.eu wrote: On 08 Mar 2013, at 11:16, Sven Van Caekenberghe s...@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
Re: [Pharo-project] VM Crashes
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. You can provide a setting to disable the warning manually, which we can include in the standard distro.
Re: [Pharo-project] VM Crashes
On 08 Mar 2013, at 13:09, Camillo Bruni camillobr...@gmail.com wrote: On 2013-03-08, at 11:53, Sven Van Caekenberghe s...@stfx.eu wrote: On 08 Mar 2013, at 11:16, Sven Van Caekenberghe s...@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
Re: [Pharo-project] VM Crashes
included :) On Mar 8, 2013, at 2:52 PM, Sven Van Caekenberghe s...@stfx.eu wrote: Hi Esteban, On 08 Mar 2013, at 12:44, Esteban Lorenzano esteba...@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 s...@stfx.eu wrote: On 08 Mar 2013, at 11:16, Sven Van Caekenberghe s...@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
Re: [Pharo-project] VM Crashes
Thanks. But my 2nd and 3rd runs crashed, both at Smalltalk stack dump: 0xbf9c4c18 M MethodDictionary(Object)becomeForward: 0x79299080: a(n) MethodDictionary 0xbf9c4c44 M MethodDictionarygrow 0x79299080: a(n) MethodDictionary 0xbf9c4c5c M MethodDictionary(HashedCollection)fullCheck 0x79299080: a(n) MethodDictionary 0xbf9c4c78 M MethodDictionaryat: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 esteba...@gmail.com wrote: included :) On Mar 8, 2013, at 2:52 PM, Sven Van Caekenberghe s...@stfx.eu wrote: Hi Esteban, On 08 Mar 2013, at 12:44, Esteban Lorenzano esteba...@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 s...@stfx.eu wrote: On 08 Mar 2013, at 11:16, Sven Van Caekenberghe s...@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
Re: [Pharo-project] VM Crashes
On 8 March 2013 15:58, Sven Van Caekenberghe s...@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 MethodDictionarygrow 0x79299080: a(n) MethodDictionary 0xbf9c4c5c M MethodDictionary(HashedCollection)fullCheck 0x79299080: a(n) MethodDictionary 0xbf9c4c78 M MethodDictionaryat: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 esteba...@gmail.com wrote: included :) On Mar 8, 2013, at 2:52 PM, Sven Van Caekenberghe s...@stfx.eu wrote: Hi Esteban, On 08 Mar 2013, at 12:44, Esteban Lorenzano esteba...@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 s...@stfx.eu wrote: On 08 Mar 2013, at 11:16, Sven Van Caekenberghe s...@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
Re: [Pharo-project] VM Crashes
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.
Re: [Pharo-project] VM Crashes
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 MethodDictionarygrow 0x79299080: a(n) MethodDictionary 0xbf9c4c5c M MethodDictionary(HashedCollection)fullCheck 0x79299080: a(n) MethodDictionary 0xbf9c4c78 M MethodDictionaryat: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 lt; estebanlm@ gt; wrote: included :) On Mar 8, 2013, at 2:52 PM, Sven Van Caekenberghe lt; sven@ gt; wrote: Hi Esteban, On 08 Mar 2013, at 12:44, Esteban Lorenzano lt; estebanlm@ gt; 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 lt; sven@ gt; wrote: On 08 Mar 2013, at 11:16, Sven Van Caekenberghe lt; sven@ gt; 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
[Pharo-project] VM Crashes
To join in again, my regression tests still seem to fail loading. So it looks like a similar effect as what sven experiences! https://ci.inria.fr/pharo/job/Pharo-2.0-Regression-Tests/VM=PharoVM,label=mac/110/console
Re: [Pharo-project] VM Crashes
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 pdebr...@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 MethodDictionarygrow 0x79299080: a(n) MethodDictionary 0xbf9c4c5c M MethodDictionary(HashedCollection)fullCheck 0x79299080: a(n) MethodDictionary 0xbf9c4c78 M MethodDictionaryat: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 lt; estebanlm@ gt; wrote: included :) On Mar 8, 2013, at 2:52 PM, Sven Van Caekenberghe lt; sven@ gt; wrote: Hi Esteban, On 08 Mar 2013, at 12:44, Esteban Lorenzano lt; estebanlm@ gt; 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 lt; sven@ gt; wrote: On 08 Mar 2013, at 11:16, Sven Van Caekenberghe lt; sven@ gt; 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
Re: [Pharo-project] VM Crashes
On Fri, Mar 8, 2013 at 11:44 AM, Sven Van Caekenberghe s...@stfx.eu wrote: On 08 Mar 2013, at 13:09, Camillo Bruni camillobr...@gmail.com wrote: On 2013-03-08, at 11:53, Sven Van Caekenberghe s...@stfx.eu wrote: On 08 Mar 2013, at 11:16, Sven Van Caekenberghe s...@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. Indeed, we noticed this as well when benchmarking Tanker to replace source compilation in Monticello. We got to a similar conclusion. Quite a challenge to optimize if you ask me. - Batch notifications: do not do a notification per method/class added. Instead do one notification with all the methods/classes together. -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] VM Crashes
List, I hope you realize I'm motivated to investigate VM crashes. Esteban reports that the VM is now more stable w.r.t. becomeForward: after I debugged load cases a couple of week ago. But I could do with some help. It really helps to be provided with an image that reproduces the bug in start-up. e.g. evaluating a doit that saves and then invokes crashing code: Smalltalk saveAs: 'crash'. Gofer it url: 'http://www.squeaksource.com/MetacelloRepository'; package: 'ConfigurationOfFFI'; load. (Smalltalk at: #ConfigurationOfFFI) project stableVersion load. This saves me a lot of time. I have a day job that does not pay me to investigate Cog crashes. Your help is most appreciated. On Fri, Mar 8, 2013 at 8:14 AM, Camillo Bruni camillobr...@gmail.com wrote: To join in again, my regression tests still seem to fail loading. So it looks like a similar effect as what sven experiences! https://ci.inria.fr/pharo/job/Pharo-2.0-Regression-Tests/VM=PharoVM,label=mac/110/console -- best, Eliot
Re: [Pharo-project] VM Crashes
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
Re: [Pharo-project] VM Crashes
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
Re: [Pharo-project] VM Crashes
On Mar 8, 2013, at 5:03 PM, Paul DeBruicker pdebr...@gmail.com wrote: 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? Paul we will provide one VM :) after the message could be a bit more explicit. and one image + vm combo will be offered. This is just that we ran after this become: bug since a couple of months and we are getting to the situation were we could reproduce it. Stef
Re: [Pharo-project] VM Crashes
List, I hope you realize I'm motivated to investigate VM crashes. Esteban reports that the VM is now more stable w.r.t. becomeForward: after I debugged load cases a couple of week ago. But I could do with some help. It really helps to be provided with an image that reproduces the bug in start-up. e.g. evaluating a doit that saves and then invokes crashing code: Smalltalk saveAs: 'crash'. Gofer it url: 'http://www.squeaksource.com/MetacelloRepository'; package: 'ConfigurationOfFFI'; load. (Smalltalk at: #ConfigurationOfFFI) project stableVersion load. This saves me a lot of time. I have a day job that does not pay me to investigate Cog crashes. Your help is most appreciated. Your too. Yes getting reproducible cases is a key aspect. Esteban and Igor spent some days checking for this and other problems (that nicolas experienced on his servers). Stef
[Pharo-project] VM Crashes
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=s...@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 esteba...@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 MethodDictionarygrow 0x7948f890: a(n) MethodDictionary 0xbfd22768 M MethodDictionary(HashedCollection)fullCheck 0x7948f890: a(n) MethodDictionary 0xbfd22784 M MethodDictionaryat: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 MethodAdditioninstallMethod 0x79091124: a(n) MethodAddition 0xbfd22840 M [] in MCPackageLoaderbasicLoad 0x7904c5c8: a(n) MCPackageLoader 0xbfd22860 M OrderedCollectiondo: 0x7904c698: a(n) OrderedCollection 0xbfd2287c M [] in MCPackageLoaderbasicLoad 0x7904c5c8: a(n) MCPackageLoader 0xbfd22898 M BlockClosureon:do: 0x79068044: a(n) BlockClosure 0xbfd1d6f0 M [] in MCPackageLoaderbasicLoad 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d710 M BlockClosureensure: 0x79067fc8: a(n) BlockClosure 0xbfd1d72c M MCPackageLoaderbasicLoad 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d74c I [] in MCPackageLoaderloadWithNameLike: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d770 I [] in MCPackageLoaderuseChangeSetNamed:during: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d790 M BlockClosureensure: 0x79067f04: a(n) BlockClosure 0xbfd1d7bc I MCPackageLoaderuseChangeSetNamed:during: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d7e4 I MCPackageLoaderuseNewChangeSetNamedLike:during: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d80c I MCPackageLoaderloadWithNameLike: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d834 I MCVersionLoaderloadWithNameLike: 0x7904c3a8: a(n) MCVersionLoader 0xbfd1d858 I MCVersionLoaderload 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 MetacelloPharoPlatformdo:displaying: 0x77cdd608: a(n) MetacelloPharoPlatform 0xbfd17740 M BlockClosurecull: 0x7904bf80: a(n) BlockClosure 0xbfd17760 M [] in Jobrun 0x7904bf98: a(n) Job 0xbfd1777c M BlockClosureon:do: 0x7904c0e8: a(n) BlockClosure 0xbfd177a0 M [] in Jobrun 0x7904bf98: a(n) Job 0xbfd177c0 M BlockClosureensure: 0x7904c068: a(n) BlockClosure 0xbfd177e0 M Jobrun 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 MetacelloPharoPlatformdo:displaying: 0x77cdd608: a(n) MetacelloPharoPlatform 0xbfd17870 I MetacelloLoadingMCSpecLoader(MetacelloCommonMCSpecLoader)loadPackageDirective:gofer:
Re: [Pharo-project] VM Crashes
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. Esteban On Mar 7, 2013, at 2:17 PM, Sven Van Caekenberghe s...@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=s...@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 esteba...@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 MethodDictionarygrow 0x7948f890: a(n) MethodDictionary 0xbfd22768 M MethodDictionary(HashedCollection)fullCheck 0x7948f890: a(n) MethodDictionary 0xbfd22784 M MethodDictionaryat: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 MethodAdditioninstallMethod 0x79091124: a(n) MethodAddition 0xbfd22840 M [] in MCPackageLoaderbasicLoad 0x7904c5c8: a(n) MCPackageLoader 0xbfd22860 M OrderedCollectiondo: 0x7904c698: a(n) OrderedCollection 0xbfd2287c M [] in MCPackageLoaderbasicLoad 0x7904c5c8: a(n) MCPackageLoader 0xbfd22898 M BlockClosureon:do: 0x79068044: a(n) BlockClosure 0xbfd1d6f0 M [] in MCPackageLoaderbasicLoad 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d710 M BlockClosureensure: 0x79067fc8: a(n) BlockClosure 0xbfd1d72c M MCPackageLoaderbasicLoad 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d74c I [] in MCPackageLoaderloadWithNameLike: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d770 I [] in MCPackageLoaderuseChangeSetNamed:during: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d790 M BlockClosureensure: 0x79067f04: a(n) BlockClosure 0xbfd1d7bc I MCPackageLoaderuseChangeSetNamed:during: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d7e4 I MCPackageLoaderuseNewChangeSetNamedLike:during: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d80c I MCPackageLoaderloadWithNameLike: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d834 I MCVersionLoaderloadWithNameLike: 0x7904c3a8: a(n) MCVersionLoader 0xbfd1d858 I MCVersionLoaderload 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 MetacelloPharoPlatformdo:displaying: 0x77cdd608: a(n) MetacelloPharoPlatform 0xbfd17740 M BlockClosurecull: 0x7904bf80: a(n) BlockClosure 0xbfd17760 M [] in Jobrun 0x7904bf98: a(n) Job 0xbfd1777c M BlockClosureon:do: 0x7904c0e8: a(n) BlockClosure 0xbfd177a0 M [] in Jobrun 0x7904bf98: a(n) Job 0xbfd177c0 M BlockClosureensure: 0x7904c068: a(n) BlockClosure 0xbfd177e0 M Jobrun 0x7904bf98: a(n) Job 0xbfd177f8 M
Re: [Pharo-project] VM Crashes
Hi Esteban, On 07 Mar 2013, at 15:02, Esteban Lorenzano esteba...@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 s...@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=s...@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 esteba...@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 MethodDictionarygrow 0x7948f890: a(n) MethodDictionary 0xbfd22768 M MethodDictionary(HashedCollection)fullCheck 0x7948f890: a(n) MethodDictionary 0xbfd22784 M MethodDictionaryat: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 MethodAdditioninstallMethod 0x79091124: a(n) MethodAddition 0xbfd22840 M [] in MCPackageLoaderbasicLoad 0x7904c5c8: a(n) MCPackageLoader 0xbfd22860 M OrderedCollectiondo: 0x7904c698: a(n) OrderedCollection 0xbfd2287c M [] in MCPackageLoaderbasicLoad 0x7904c5c8: a(n) MCPackageLoader 0xbfd22898 M BlockClosureon:do: 0x79068044: a(n) BlockClosure 0xbfd1d6f0 M [] in MCPackageLoaderbasicLoad 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d710 M BlockClosureensure: 0x79067fc8: a(n) BlockClosure 0xbfd1d72c M MCPackageLoaderbasicLoad 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d74c I [] in MCPackageLoaderloadWithNameLike: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d770 I [] in MCPackageLoaderuseChangeSetNamed:during: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d790 M BlockClosureensure: 0x79067f04: a(n) BlockClosure 0xbfd1d7bc I MCPackageLoaderuseChangeSetNamed:during: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d7e4 I MCPackageLoaderuseNewChangeSetNamedLike:during: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d80c I MCPackageLoaderloadWithNameLike: 0x7904c5c8: a(n) MCPackageLoader 0xbfd1d834 I MCVersionLoaderloadWithNameLike: 0x7904c3a8: a(n) MCVersionLoader 0xbfd1d858 I MCVersionLoaderload 0x7904c3a8: a(n) MCVersionLoader 0xbfd1d878 I MetacelloGoferLoad(GoferLoad)execute 0x7904c398: a(n) MetacelloGoferLoad 0xbfd1d8a0 I [] in MetacelloLoadingMCSpecLoader(MetacelloCommonMCSpecLoader)loadPackageDirective:gofer: 0x7904be3c: a(n)
Re: [Pharo-project] VM Crashes
On 07 Mar 2013, at 15:31, Sven Van Caekenberghe s...@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
Re: [Pharo-project] VM Crashes
vm version? On Mar 7, 2013, at 4:35 PM, Sven Van Caekenberghe s...@stfx.eu wrote: On 07 Mar 2013, at 15:31, Sven Van Caekenberghe s...@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
Re: [Pharo-project] VM Crashes
On 2013-03-07, at 16:35, Sven Van Caekenberghe s...@stfx.eu wrote: On 07 Mar 2013, at 15:31, Sven Van Caekenberghe s...@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
Re: [Pharo-project] VM Crashes
On 2013-03-07, at 16:58, Sven Van Caekenberghe s...@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 esteba...@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/
Re: [Pharo-project] VM Crashes
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 s...@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 esteba...@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 s...@stfx.eu wrote: On 07 Mar 2013, at 15:31, Sven Van Caekenberghe s...@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
Re: [Pharo-project] VM Crashes
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 esteba...@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 esteba...@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 s...@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 esteba...@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 s...@stfx.eu wrote: On 07 Mar 2013, at 15:31, Sven Van Caekenberghe s...@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
Re: [Pharo-project] VM Crashes
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 esteba...@gmail.com mailto:esteba...@gmail.com wrote: vm version? On both 32 and 64 bit... On Mar 7, 2013, at 4:35 PM, Sven Van Caekenberghe s...@stfx.eu mailto:s...@stfx.eu wrote: On 07 Mar 2013, at 15:31, Sven Van Caekenberghe s...@stfx.eu mailto:s...@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
Re: [Pharo-project] VM Crashes
On Thu, Mar 7, 2013 at 9:05 AM, Jan Vrany jan.vr...@fit.cvut.cz wrote: 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. We know what the bug is; attempting to become jitted methods. I think I have a fix. I did two versions of it recently. Esteban is trying to get people to try and reproduce the crash with the latest VM. I *think* can tell Sven's crash above is not using the latest VM because it is crashing with a segmentation fault instead of exiting with an error message. I expect the VM to abort with an error message that reads either attempt to become two cogged methods or attempt to become cogged method into different method On 07 Mar 2013, at 16:40, Esteban Lorenzano esteba...@gmail.com mailto:esteba...@gmail.com wrote: vm version? On both 32 and 64 bit... On Mar 7, 2013, at 4:35 PM, Sven Van Caekenberghe s...@stfx.eu mailto:s...@stfx.eu wrote: On 07 Mar 2013, at 15:31, Sven Van Caekenberghe s...@stfx.eu mailto:s...@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 -- best, Eliot
Re: [Pharo-project] VM Crashes
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 esteba...@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 paul34420 Dec 12 07:07 libFT2Plugin.so -rwxrwxr-x 1 paul paul34639 Dec 12 07:08 libSqueakFFIPrims.so -rwxrwxr-x 1 paul paul71180 Dec 12 07:08 libB3DAcceleratorPlugin.so -rwxrwxr-x 1 paul paul21929 Dec 12 07:08 libSqueakSSL.so -rwxrwxr-x 1 paul paul12230 Dec 12 07:08 libInternetConfigPlugin.so -rwxrwxr-x 1 paul paul14461 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 paul28640 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.
Re: [Pharo-project] VM Crashes
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 urlA 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 pdebr...@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 esteba...@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 paul34420 Dec 12 07:07 libFT2Plugin.so -rwxrwxr-x 1 paul paul34639 Dec 12 07:08 libSqueakFFIPrims.so -rwxrwxr-x 1 paul paul71180 Dec 12 07:08 libB3DAcceleratorPlugin.so -rwxrwxr-x 1 paul paul21929 Dec 12 07:08 libSqueakSSL.so -rwxrwxr-x 1 paul paul12230 Dec 12 07:08 libInternetConfigPlugin.so -rwxrwxr-x 1 paul paul14461 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 paul28640 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.
Re: [Pharo-project] VM Crashes
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.
Re: [Pharo-project] VM Crashes
On 07 Mar 2013, at 20:37, Paul DeBruicker pdebr...@gmail.com wrote: 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? I thought your config/code was public - no problem if that isn't so (yet).
Re: [Pharo-project] VM Crashes
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.
Re: [Pharo-project] VM Crashes
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. On Thu, Mar 7, 2013 at 11:09 AM, Paul DeBruicker pdebr...@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 esteba...@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 paul34420 Dec 12 07:07 libFT2Plugin.so -rwxrwxr-x 1 paul paul34639 Dec 12 07:08 libSqueakFFIPrims.so -rwxrwxr-x 1 paul paul71180 Dec 12 07:08 libB3DAcceleratorPlugin.so -rwxrwxr-x 1 paul paul21929 Dec 12 07:08 libSqueakSSL.so -rwxrwxr-x 1 paul paul12230 Dec 12 07:08 libInternetConfigPlugin.so -rwxrwxr-x 1 paul paul14461 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 paul28640 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, Eliot
Re: [Pharo-project] VM Crashes
Hi Eliot, On 07 Mar 2013, at 23:12, Eliot Miranda eliot.mira...@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 + ... 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); spacetimezone]. ^ dateString asDateAndTime Sven
Re: [Pharo-project] VM Crashes
Eliot Miranda-2 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. -- best, Eliot Right. Sorry. I was unhelpfully pointing out that the scripts that load the latest Pharo 2 images do not load a recent VM. Finding and using the latest VM does fix it for me. I made a different question about that here: http://forum.world.st/Is-ciPharo20CogVM-sh-downloading-a-VM-from-December-td4675610.html Whether that is desired or undesired I don't know but it seems counter-intuitive that if you want the latest image you would also want an outdated VM. I think it is undesirable, but here we are. I'm hopeful that the scripts have recently changed to load older vms and its a bug that will get fixed. For others who read this new pharo team created VMs are here: http://pharo.gforge.inria.fr/ci/vm/pharo/ and Eliots are here: http://www.mirandabanda.org/files/Cog/VM/ -- View this message in context: http://forum.world.st/VM-Crashes-tp4675526p4675630.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] VM Crashes
On Thu, Mar 7, 2013 at 2:23 PM, Sven Van Caekenberghe s...@stfx.eu wrote: Hi Eliot, On 07 Mar 2013, at 23:12, Eliot Miranda eliot.mira...@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 ? Yes. It's using a primitive my Cog VMs don't have. :( In any case, Esteban has (I believe) updated the Pharo VM with the relevant fixes. So the solution is to use the latest Pharo VM. Apologies for my intemperate tone. IO notied after I hit send that you'd seen my mention of fixed VMs earlier. 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 + ... 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); spacetimezone]. ^ dateString asDateAndTime Sven -- best, Eliot
Re: [Pharo-project] VM Crashes
Just to remove doubt, you might try http://www.memtest.org/ 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 urlA 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 pdebr...@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 esteba...@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 paul34420 Dec 12 07:07 libFT2Plugin.so -rwxrwxr-x 1 paul paul34639 Dec 12 07:08 libSqueakFFIPrims.so -rwxrwxr-x 1 paul paul71180 Dec 12 07:08 libB3DAcceleratorPlugin.so -rwxrwxr-x 1 paul paul21929 Dec 12 07:08 libSqueakSSL.so -rwxrwxr-x 1 paul paul12230 Dec 12 07:08 libInternetConfigPlugin.so -rwxrwxr-x 1 paul paul14461 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 paul28640 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.
Re: [Pharo-project] VM Crashes
On 8 March 2013 00:14, Ben Coman b...@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 urlA 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 pdebr...@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 esteba...@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 paul34420 Dec 12 07:07 libFT2Plugin.so -rwxrwxr-x 1 paul paul34639 Dec 12 07:08 libSqueakFFIPrims.so -rwxrwxr-x 1 paul paul71180 Dec 12 07:08 libB3DAcceleratorPlugin.so -rwxrwxr-x 1 paul paul21929 Dec 12 07:08 libSqueakSSL.so -rwxrwxr-x 1 paul paul12230 Dec 12 07:08 libInternetConfigPlugin.so -rwxrwxr-x 1 paul paul14461 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 paul28640 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.
Re: [Pharo-project] VM Crashes
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.mira...@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
