Issue 4003 in pharo: Build of Core 1.3 broken because of integration of 13147

Status: Accepted
Owner: [hidden email]
Labels: Milestone-1.3

New issue 4003 by [hidden email]: Build of Core 1.3 broken because  
of integration of 13147
http://code.google.com/p/pharo/issues/detail?id=4003

Issue 13147 has some problem:

+ /builds/builder/build13.sh -i gforgeCore13 -s update -o PharoCore-1.3

Segmentation fault

2031166104 Behavior>allInstancesDo:
2031165968 Behavior>allSubInstancesDo:
2031165876 Behavior>allSubInstances
2031165724 >shutDown:
2031165632 SmalltalkImage>send:toClassesNamedIn:with:
2031165540 BlockClosure>on:do:
2031165448 SmalltalkImage>send:toClassesNamedIn:with:
2031148208 OrderedCollection>do:
2031148116 SmalltalkImage>send:toClassesNamedIn:with:
2031148024 SmalltalkImage>processShutDownList:
2031132380 SmalltalkImage>snapshot:andQuit:
2031132288 UndefinedObject>?
2028739856 WorldState>runStepMethodsIn:
2028739764 PasteUpMorph>runStepMethods
2025422416 WorldState>doOneCycleNowFor:
2025422324 WorldState>doOneCycleFor:
2025422232 PasteUpMorph>doOneCycle
2015335972 >?
2015335880 BlockClosure>?
/tmp/hudson2223222193118569935.sh: line 3: 19842 Aborted                  
/builds/builder/build13.sh -i gforgeCore13 -s update -o PharoCore-1.3
Archiving artifacts
Enregistrement des r?sultats des tests

Comment #1 on issue 4003 by [hidden email]: Build of Core 1.3 broken  
because of integration of 13147
http://code.google.com/p/pharo/issues/detail?id=4003

I think changing how scripts are loaded in an image started with a script  
is not good.

The image itself when updated seems good.

So I update the pre-build and we will see.

Comment #2 on issue 4003 by [hidden email]: Build of Core 1.3 broken  
because of integration of 13147
http://code.google.com/p/pharo/issues/detail?id=4003

So I did a new prebuild.

https://gforge.inria.fr/frs/download.php/28478/PharoCore-1.3-13147.zip

But now Hudson hangs when loading the script.

So something is completely broken.


https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/215/console

Comment #3 on issue 4003 by [hidden email]: Build of Core 1.3 broken  
because of integration of 13147
http://code.google.com/p/pharo/issues/detail?id=4003

I think I found it. I added

CommandLine initialize

to the postscript but forgot

CodeLoader initialize

Comment #4 on issue 4003 by [hidden email]: Build of Core 1.3 broken  
because of integration of 13147
http://code.google.com/p/pharo/issues/detail?id=4003

Now the script loads but we get a walkback. One that does not kill the  
image interestingly.

https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/ws/PharoCore-1.3/PharoDebug.log/*view*/

Updates:
        Status: FixToInclude

Comment #5 on issue 4003 by [hidden email]: Build of Core 1.3 broken  
because of integration of 13147
http://code.google.com/p/pharo/issues/detail?id=4003

I think the problem is a exception handler that swallows all Exceptions  
(ProgressNotification, too) in headless mode. (leftover from before the  
real  headless mode).

fix attached.

Attachments:
        SmalltalkImage-sendtoClassesNamedInwith.st  886 bytes

Updates:
        Status: Started

Comment #6 on issue 4003 by [hidden email]: Build of Core 1.3 broken  
because of integration of 13147
http://code.google.com/p/pharo/issues/detail?id=4003

Nope. Now we don't get a debug log anymore but it nevertheless hangs.

https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/219/console

Comment #7 on issue 4003 by [hidden email]: Build of Core 1.3 broken  
because of integration of 13147
http://code.google.com/p/pharo/issues/detail?id=4003

here the part of code which responsible for doing startup:

        self processStartUpList: resuming.
        resuming
                ifTrue: [ self recordStartupStamp ].
        UIManager default onSnapshot: resuming. "Now it's time to raise an error"

as you can see, the process list are ehmm.. processed before UIManager  
takes a control (and before switching to non-interactive mode).

It means that if any startup procedure added by some arbitrary class will  
fail with error, it will end up using old UIManager, which could open a  
debugger window and waiting for user's interaction.
 From other side, im not sure it would be wise to switch UIManager before  
processing the startup list, because it in own turn could depend on startup  
of things like Delay etc.

Updates:
        Status: Closed

Comment #8 on issue 4003 by [hidden email]: Build of Core 1.3 broken  
because of integration of 13147
http://code.google.com/p/pharo/issues/detail?id=4003

fixed