GemTalk / JadeiteForPharo

IDE for GemStone Smalltalk application development in Pharo using Rowan code management
MIT License
0 stars 0 forks source link

Connection Launcher after stone has been killed brings up debugger ... #81

Open dalehenrich opened 3 months ago

dalehenrich commented 3 months ago

Here's the stack that produces the hang ... forEric.log

ericwinger commented 3 months ago

Was able to reproduce the error. However, I didn't get the hung image. Instead a Pharo debugger was raised.

When GciThreadSafeInterface>>logoutNoError: gets an error logging it out, it signals the error to Pharo and a pharo debugger should appear. Since no debugger was raised, and instead the image was hung, that appears to be the bug.

If it reproduces, I'd like to know a couple things:

dalehenrich commented 3 months ago

Did your reproduction test case get the same stack ... as reported ... I'm pretty sure that the stack came from the ctl-. so that stack could give clues as to what was actually hung ...

In #82 ... I got a debugger that appeared when I was taking a screen shot ... so it seems that weird process schedulers could delay hangs until the damaged thread gets a chance to run ...

In THEORY

dalehenrich commented 2 months ago

The original hang has been fixed, but since a debugger is expected if you attempt to logout from a stone that is no longer running perhaps we could get a an error window instead of a debugger:

[result signal: result message ] in GciThreadSafeInterface>>logoutNoError: in Block: [result signal: result message ]
FullBlockClosure(BlockClosure)>>ensure:
GciThreadSafeInterface>>logoutNoError:
GciThreadSafeInterface>>logout
[ 
      (self class sessionIsValid: self) ifTrue: [ gciInterface logout ] ] in GsSession>>logout in Block: [ ...
FullBlockClosure(BlockClosure)>>ensure:
GsSession>>logout
JadeiteGCIConnectionProfile>>disconnect
JadeiteConnectionLauncher>>disconnect
[ self disconnect ] in JadeiteConnectionLauncher>>initializeButtons in Block: [ self disconnect ]
SpButtonPresenter>>performAction
SpMorphicButtonAdapter>>action
SpPluggableButtonMorph(PluggableButtonMorph)>>performAction:
[:m |
        (m containsPoint: evt cursorPoint) ifTrue: [m enabled ifTrue: [ m performAction: evt ]]] in SpPluggableButtonMorph(PluggableButtonMorph)>>mouseUp: in Block: [:m |...
Array(SequenceableCollection)>>do:
SpPluggableButtonMorph(PluggableButtonMorph)>>mouseUp:
SpPluggableButtonMorph(Morph)>>handleMouseUp:
MouseButtonEvent>>sentTo:
SpPluggableButtonMorph(Morph)>>handleEvent:
SpPluggableButtonMorph(Morph)>>handleFocusEvent:
[
        result := focusHolder handleFocusEvent: transformedEvent.
    ] in HandMorph>>sendFocusEvent:to:clear: in Block: [...
FullBlockClosure(BlockClosure)>>on:do:
WorldMorph>>becomeActiveDuring:
HandMorph>>sendFocusEvent:to:clear:
HandMorph>>sendEvent:focus:clear:
HandMorph>>sendMouseEvent:
HandMorph>>handleEvent:
[
        (morphicWorld activeHand isNotNil and: [ anEvent hand isNotNil ]) ifTrue: [
            morphicWorld activeHand handleEvent: anEvent
        ]
    ] in OSWindowMorphicEventHandler>>dispatchMorphicEvent: in Block: [...
WorldState>>runStepMethodsIn:
WorldMorph>>runStepMethods
WorldState>>doOneCycleFor:
WorldMorph>>doOneCycleNow
WorldMorph>>doOneCycle
[
        | extraWorldsToDraw |
        extraWorldsToDraw := ExtraWorldListMutex critical: [
                                 self extraWorldList ].
        extraWorldsToDraw do: [ :world | world doOneCycle ].

        (self currentWorld isNotNil and: [
             (extraWorldsToDraw includes: self currentWorld) not ]) ifTrue: [
            self currentWorld doOneCycle ] ] in WorldMorph class>>doOneCycle in Block: [...
FullBlockClosure(BlockClosure)>>ensure:
WorldState class>>doDrawCycleWith:
WorldMorph class>>doOneCycle
MorphicRenderLoop>>doOneCycle
MorphicRenderLoop>>doOneCycleWhile:
[ MorphicRenderLoop new doOneCycleWhile: [ true ] ] in MorphicUIManager>>spawnNewProcess in Block: [ MorphicRenderLoop new doOneCycleWhile: [ tru[..]
[self value.
            "IMPORTANT: Do not step over next line of code. See method comments for details"
            Processor terminateRealActive] in FullBlockClosure(BlockClosure)>>newProcess in Block: [self value....

Retitled changed to feature request ...

A socket error on logout indicates that the stone is most likely already shut down ... so offering option to debug (I think that's what I see in Dolphin) is much better, especially if we know that the stone is shut down ... then continuing with the disconnect procedure ignoring the socket error is much more friendly, since right now I have to close the debugger and press disconnect again to get JfP in a state that I can move forward ...