[Pharo-dev] [Debugger] Is "run to here" broken?

Ben Coman btc at openinworld.com
Mon Nov 13 08:08:55 EST 2017


On Mon, Nov 13, 2017 at 8:40 PM, Thomas Dupriez <
thomas.dupriez at ens-paris-saclay.fr> wrote:

> I dug a bit in this issue. Here are the results:
>
>
> # Problem raised by Stephanne
> Code like the following is open in the debugger:
>
>     `myMethod
>         1+1. <PROGRAMCOUNTER>
>         MyClass new myEvalBlock: [
>             2+2. <CURSOR>
>         ].
>         3+3.`
>
> The program counter is on the 1+1, the cursor is at the end of the 2+2
> line.
> Right-click, "Run to here".
> -> the program counter moves to the 3+3, and does not stop at the 2+2
> (where the cursor is). Even though the 2+2 does get evaluated (the
> myEvalBlock method evaluates the blocks it receives).
> If there was no code after the block, the debugger would jump back to the
> caller of myMethod.
>
> # Why this happens
> The implementation of RunToHere (source code below) is basically to
> stepOver until the context is different or the source code position of the
> program counter is higher or equal to the source code position of the
> cursor/selection.
>
> Since the debugger uses stepOver, it executes myEvalBlock without
> stopping, reaches the 3+3 and see it has gone further than the source code
> position of the cursorm so it stops.
>
> Source code of DebugSession>>#runToSelection:inContext:
>
>     `runToSelection: selectionInterval inContext: aContext
>         "Attempt to step over instructions in selectedContext until the
>         execution reaches the selected instruction. This happens when the
>         program counter passes the begining of selectionInterval.
>
>         A not nill and valid interval is expected."
>
>         (self pcRangeForContext: aContext) first >= selectionInterval first
>             ifTrue: [ ^self ].
>         self stepOver: aContext.
>         [ aContext == self interruptedContext and: [ (self
> pcRangeForContext: aContext) first < selectionInterval first ] ]
>             whileTrue: [ self stepOver: aContext ]`
>
> # Observations and thoughts
> - Replacing the stepOver with a stepInto -> This made the RunToHere stops
> when resolving the 'new' message (because the context changes).
>

Thanks for looking into this Thomas.
What happens if you use stepThrough rather than stepInto?

cheers -ben


>
> - Replacing the stepOver with stepInto and removing the equal condition on
> contexts -> The RunToHere goes to the 3+3. Looking at the source code
> position of the program counter, it doesn't enter the block and seems to
> resolve it in a single step. I don't really get why that is, considering
> using the stepInto button of the debugger does enter the block. Here is the
> series of source code positions of the program counter during the
> RunToHere: (21 to: 22)(34 to: 36)(34 to: 36)(49 to: 60)(38 to: 60)(38 to:
> 60)(65 to: 66).
> However, removing the equal condition on contexts means that if the method
> call returns before reaching the cursor, it won't stop!
>
> - An idea could be to have the RunToHere place a metalink on the selected
> node and let the execution run until it hits the metalink, which then
> updates the debugger. Potential problems are that it implies installing a
> metalink on a method that is already on the stack, which may not be that
> easy to do properly (in particular, it affects the program counter since it
> changes the bytecode), and there is the potential case where the metalink
> is never reached (for example imagine the myEvalBlock: method of my example
> is just storing the block and not evaluating it).
>
>
> Cheers,
> Thomas
>
>
>
> Le 09/11/2017 à 22:06, Stephane Ducasse a écrit :
>
>> Agreed. Thomas? It would be a good bone to ... (Un bon os a ronger) .
>>
>> Stef
>>
>> On Thu, Nov 9, 2017 at 4:32 AM, Tudor Girba <tudor at tudorgirba.com> wrote:
>>
>>> Hi,
>>>
>>> The basic tools, such as debugger, are expected to work. If something
>>> does not work, it’s a bug.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> On Nov 8, 2017, at 11:59 PM, Tim Mackinnon <tim at testit.works> wrote:
>>>>
>>>> I think it's broken in Pharo 6 too, as I often find it unreliable.
>>>>
>>>> It's hard to know what should work anymore - we really need a
>>>> stabilisation release to let the dust settle.
>>>>
>>>> I'm always a bit reticent to report things as I'm not sure what you
>>>> expect to work.
>>>>
>>>> Tim
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 8 Nov 2017, at 20:40, Stephane Ducasse <stepharo.self at gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> I have the following method and I have my cursor -MY CURSOR HERE-
>>>>> I select the menu run to here and .... I exit the method.
>>>>> :(
>>>>>
>>>>> Is run to here working in Pharo 70?
>>>>> I start to get worry about the number of bugs I get when using Pharo70.
>>>>>
>>>>> Stef
>>>>>
>>>>>
>>>>> fileOut
>>>>> "File out the receiver, to a file whose name is a function of the
>>>>> change-set name and a unique numeric tag."
>>>>>
>>>>> | nameToUse |
>>>>> self halt.
>>>>> self class promptForDefaultChangeSetDirectoryIfNecessary.
>>>>> nameToUse := (self defaultChangeSetDirectory / self name , 'cs')
>>>>> nextVersion basename.
>>>>> UIManager default
>>>>> showWaitCursorWhile:
>>>>> [
>>>>> | internalStream |
>>>>> internalStream := (String new: 10000) writeStream.
>>>>>
>>>>> -MY CURSOR HERE-
>>>>>
>>>>> internalStream
>>>>> header;
>>>>> timeStamp.
>>>>> self fileOutPreambleOn: internalStream.
>>>>> self fileOutOn: internalStream.
>>>>> self fileOutPostscriptOn: internalStream.
>>>>> CodeExporter
>>>>> writeSourceCodeFrom: internalStream
>>>>> baseName: (nameToUse copyFrom: 1 to: nameToUse size - 3)
>>>>> isSt: false ]
>>>>>
>>>>>
>>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>>
>>> "Value is always contextual."
>>>
>>>
>>>
>>>
>>>
>>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171113/68e04cf0/attachment-0002.html>


More information about the Pharo-dev mailing list