[Vm-dev] [squeak-dev] Opening two debuggers in a single doit

Eliot Miranda eliot.miranda at gmail.com
Thu Jan 25 15:21:48 UTC 2018


Hi Marcel,

On Thu, Jan 25, 2018 at 1:04 AM, Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Well, I moved the flag inside the deferred call. It works fine for me. :-)
>
> See, if it works for you as well.
>

It does.  Thank you!

BTW, here's how I'm using it:

[:m :opts|
 [StackToRegisterMappingCogit cog: m options: opts] fork.
 AltStackToRegisterMappingCogit cog: m options: opts]
value: TabbedPalette class>>#unload
value: #(ObjectMemory Spur64BitCoMemoryManager
debugBytecodePointers #(59)).

It stops two nearly identical JIT compilations of a method at a given
bytecode, saving me huge amounts of time stepping to a specific point in
two separate debuggers.

The need for editWithLabel: comes in a scan over all the methods in the
system where I open the disassembled machine code generated by each JIT, a
diff of the disassembly where the two differ, and an explorer on the
CompiledMethod.  From that I puzzle out which bytecode caused the
difference and then move to my first example to debug.  Contrast this with
two simulations of an image where the different results become apparent
long after bugs in the code produced by the incomplete refactoring of
AltStackToRegisterMappingCogit, and simulation proceeds at a stately pace.



> http://forum.world.st/The-Trunk-Tools-mt-794-mcz-tp5064330.html
> http://forum.world.st/The-Trunk-Morphic-mt-1390-mcz-tp5064331.html
>
> Best,
> Marcel
>
> Am 25.01.2018 08:57:01 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
> Hi Eliot,
>
> we should not do that. ;-) It is essential to try opening and drawing that
> debugger first before we flip ErrorRecursion back to false.
>
> I will look into your scenario. You are right, this should work:
>
> [1 halt] fork.
> Processor yield.
> 2 halt.
>
> Best,
> Marcel
>
> Am 25.01.2018 01:05:19 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
> Bob,
>
>     thank you!!  morphicOpenOn:context:label:contents:fullView: is indeed
> the method in question. So if one moves the ErrorRecursion := false outside
> of the addDeferredUIMessage: block everything works.  i.e. now the code
> reads:
>
> Project current addDeferredUIMessage:
> [ debugger := self new
> process: process
> controller: nil
> context: context.
> full
> ifTrue: [ debugger openFullNoSuspendLabel: title ]
> ifFalse:
> [ debugger
> openNotifierContents: contentsStringOrNil
> label: title ].
> debugger errorWasInUIProcess: errorWasInUIProcess.
> "Try drawing the debugger tool at least once to avoid freeze."
> Project current world displayWorldSafely].
> ErrorRecursion := false ].
>
> and the old code doesn't work:
>
> Project current addDeferredUIMessage:
> [ debugger := self new
> process: process
> controller: nil
> context: context.
> full
> ifTrue: [ debugger openFullNoSuspendLabel: title ]
> ifFalse:
> [ debugger
> openNotifierContents: contentsStringOrNil
> label: title ].
> debugger errorWasInUIProcess: errorWasInUIProcess.
> "Try drawing the debugger tool at least once to avoid freeze."
> Project current world displayWorldSafely.
> ErrorRecursion := false ]].
>
> So there question is, what are the tests for the ErrorGuard and
> ErrorRecursion?  I need to run these before committing the fix above.
>
> Bob, way to go!  Thank you.
>
> On Wed, Jan 24, 2018 at 3:52 PM, Bob Arning <arning315 at comcast.net> wrote:
>
>> I tried this in 5.1 and it worked
>>
>> Debugger class>>
>>
>> morphicOpenOn: process context: context label: title contents:
>> contentsStringOrNil fullView: full
>>     "Open a notifier in response to an error, halt, or notify. A notifier
>> view just shows a short view of the sender stack and provides a menu that
>> lets the user open a full debugger."
>>
>>     | errorWasInUIProcess debugger |
>>     ErrorRecursion ifTrue: [
>>         "self assert: process == Project current uiProcess --
>> DOCUMENTATION ONLY"
>>         ErrorRecursion := false.
>>         "^ Project current handleFatalDrawingError: title"].
>> <============commented this out
>> ...
>>
>>
>> On 1/24/18 6:31 PM, Eliot Miranda wrote:
>>
>> Hi All,
>>
>>     I'm comparing two close copies of a class in attempting a complex
>> refactoring, comparing the original code with the close copy.  In doing
>> this I need to open up two debuggers to step through the two computations
>> simultaneously.  If I try it this way, where the two JITs break at a
>> particular bytecode:
>>
>> [:m :opts|
>>  [StackToRegisterMappingCogit cog: m options: opts] fork.
>>  Processor yield.
>>  AltStackToRegisterMappingCogit cog: m options: opts]
>> value: TabbedPalette class>>#unload
>> value: #(ObjectMemory Spur64BitCoMemoryManager
>> debugBytecodePointers #(59)
>> compilationTrace 0).
>>
>> I get an emergency evaluator :-(, and if I type restart I only ever get
>> one debugger.  What's the right way to do this?
>>
>> To boil down the example I need this to work:
>>
>>     [1 halt] fork.
>>     Processor yield.
>>     2 halt
>>
>> i.e. I want to be able to get two debuggers, one open on 1 halt, and the
>> other on 2 halt.
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180125/50b034a7/attachment.html>


More information about the Vm-dev mailing list