On Fri, Dec 14, 2012 at 7:58 PM, Pavel Krivanek <pavel.krivanek@gmail.com>wrote:
On Fri, Dec 14, 2012 at 7:42 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 14 December 2012 19:33, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
On Fri, Dec 14, 2012 at 7:17 PM, Igor Stasenko <siguctua@gmail.com>
wrote:
On 14 December 2012 19:03, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
On Fri, Dec 14, 2012 at 4:35 PM, Igor Stasenko <siguctua@gmail.com> wrote:
i killled the VM with SIGUSR signal and here the stack:
Process 0x77ccf2cc priority 40 0xbff5517c I [] in Delay>wait 2035889428: a(n) Delay 0xbff551a4 I BlockClosure>ifCurtailed: 2035890000: a(n) BlockClosure 0xbff551c8 I Delay>wait 2035889428: a(n) Delay 0xbff551e8 I TimeStamp class(DateAndTime class)>waitForOffsets 2007868504: a(n) TimeStamp class 0xbff55210 I TimeStamp class(DateAndTime class)>milliSecondsSinceMidnight 2007868504: a(n) TimeStamp class 0xbff55238 I TimeStamp class(DateAndTime class)>now 2007868504: a(n) TimeStamp class 0xbff55260 I TimeStamp class>current 2007868504: a(n) TimeStamp
class
0xbff55280 I TimeStamp class>now 2007868504: a(n) TimeStamp class 0xbff552a0 I ZnClient>handleResponse 2035558752: a(n) ZnClient 0xbff552c0 I ZnClient>executeWithRedirectsRemaining: 2035558752: a(n) ZnClient 0xbff552e4 I [] in ZnClient>executeWithRetriesRemaining: 2035558752: a(n) ZnClient 0xbff55300 M BlockClosure>on:do: 2035590416: a(n) BlockClosure 0xbff55328 I ZnClient>executeWithRetriesRemaining: 2035558752: a(n) ZnClient 0xbff55344 M [] in ZnClient>executeWithTimeout 2035558752: a(n) ZnClient 0xbff55360 M BlockClosure>on:do: 2035590092: a(n) BlockClosure 0xbff55388 I [] in ZnClient>executeWithTimeout 2035558752: a(n) ZnClient 0xbff553ac I [] in ZnClient>withTimeoutDo: 2035558752: a(n) ZnClient 0xbff553d8 I [] in ZnConnectionTimeout(DynamicVariable)>value:during: 2007631496: a(n) ZnConnectionTimeout 0xbff553f8 M BlockClosure>ensure: 2035589948: a(n) BlockClosure 0xbff55424 I ZnConnectionTimeout(DynamicVariable)>value:during: 2007631496: a(n) ZnConnectionTimeout 0xbff5544c I ZnConnectionTimeout class(DynamicVariable class)>value:during: 2007997132: a(n) ZnConnectionTimeout class 0xbff55474 I ZnClient>withTimeoutDo: 2035558752: a(n) ZnClient 0xbff55498 I ZnClient>executeWithTimeout 2035558752: a(n) ZnClient 0xbff554bc I [] in ZnClient>execute 2035558752: a(n) ZnClient 0xbff554e0 I [] in ZnClient>withProgressDo: 2035558752: a(n) ZnClient 0xbff5550c I [] in ZnSignalProgress(DynamicVariable)>value:during: 2009919884: a(n) ZnSignalProgress 0xbff5552c M BlockClosure>ensure: 2035589476: a(n) BlockClosure 0xbff55558 I ZnSignalProgress(DynamicVariable)>value:during: 2009919884: a(n) ZnSignalProgress 0xbff55580 I ZnSignalProgress class(DynamicVariable class)>value:during: 2009919012: a(n) ZnSignalProgress class 0xbff555a8 I ZnClient>withProgressDo: 2035558752: a(n) ZnClient 0xbff555d4 I ZnClient>execute 2035558752: a(n) ZnClient 0xbff555f4 I ZnClient>get 2035558752: a(n) ZnClient 0xbff55614 I ZnClient>downloadTo: 2035558752: a(n) ZnClient 0xbff55640 I SmalltalkImage>downloadSources 2020677412: a(n) SmalltalkImage 0xbff55670 I SmalltalkImage>checkAndOpenSourcesAndChanges 2020677412: a(n) SmalltalkImage 0xbff55690 I SmalltalkImage>openSourceFiles 2020677412: a(n) SmalltalkImage 0xbff556a8 M SmalltalkImage class>startUp: 2020650272: a(n) SmalltalkImage class 0xbff556d0 M [] in SmalltalkImage>send:toClassesNamedIn:with: 2020677412: a(n) SmalltalkImage 0xbff556ec M BlockClosure>on:do: 2035540616: a(n) BlockClosure 0xbff5570c M SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: 2020677412: a(n) SmalltalkImage
so, it looks that we should not blame VM for 'black screen of death', but a startup code which stuck forever trying to download .sources file :)
You are right, when I add sources file next to NBCog, it works. Has anyone changed the scripts?
yes, guys added this nice feature lately.. but forgot to make it fault tolerant, i.e.
downloadSources
[ .........
] on: ??Exception?? do: [ .. ok we failed.. continue without ]
because without it, image will fail to work once you don't have network connection or simply cannot connect to urls.. for any other reason.
Yes, I know that function very well because it makes ugly dependency of the kernel on Zinc ;-). But I was talking about scripts: http://pharo.gforge.inria.fr/ci/ciPharo20NBCog.sh http://pharo.gforge.inria.fr/ci/ciNBCog.sh http://pharo.gforge.inria.fr/ci/ciPharo20.sh
but script works fine. image starts .. and then downloads .source file forever.. at least this is what happen on my ubuntu machine
hmm, you are right, I looked at an older directory created this way some time ago and the sources file has slightly newer time of creation. I supposed that the file is dowloaded by bash.
-- Pavel
I added an explicit download of the sources file to the Pharo Kernel Jobs. wget -O vm/PharoV10.sources http://pharo.gforge.inria.fr/ci/image/PharoV10.sources Maybe we should do that directly in the script. Pharo Kernel of course does not have Zinc support so it makes no sense to download it by an image by default. Cami, can you change that? We may add a special job to test downloadSources. -- Pavel
-- Pavel
-- Pavel
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.