Hello, The reason seems to be that the mechanism uses a “once” breakpoint which is for now implemented by removing the breakpoint at runtime. This leads to the debugger getting text/bytecode offset wrong as we install a different method. runTest: testSelector of: testClass | breakpoint | breakpoint := Breakpoint new node: (testClass lookupSelector: testSelector) ast; once; install. [super runTest: testSelector of: testClass] ensure: [ breakpoint remove ] I am thinking of implementing the once breakpoints using a condition instead (so that the byte code is unchanged). The other nice effect is that one can more easily re-enable those breakpoints (like haltOnce). As workaround, we can remove the “once”… as we remove the breakpoint in the ensure:, it should be removed and not stay around causing problems. (but it is there in case you would run the test again, that is why a once break is nicer). Marcus

On 15 Jun 2018, at 12:18, Marcus Denker <marcus.denker@inria.fr> wrote:

Thanks, I made a note and will look (I hope next week)

...

On 15 Jun 2018, at 01:07, Ben Coman <btc@openinworld.com> wrote:

Not sure if this is intended behaviour...

in a brand new build 71053, open a browser GTGenericStackDebuggerTest >> testBasic

right-click and choose "Debug"

the debugger opens about on the third statement. Clicking <Restart> doesn't improve things, and then clicking <Into> shows the stack on MetaLink>>uninstall.

cheers -ben

On 22 Jun 2018, at 02:54, Ben Coman <btc@openinworld.com> wrote:

...

...

On 15 Jun 2018, at 01:07, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:

Not sure if this is intended behaviour...

in a brand new build 71053, open a browser GTGenericStackDebuggerTest >> testBasic

right-click and choose "Debug"

the debugger opens about on the third statement. Clicking <Restart> doesn't improve things, and then clicking <Into> shows the stack on MetaLink>>uninstall.

cheers -ben

...

On 15 Jun 2018, at 12:18, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:

Thanks, I made a note and will look (I hope next week)

On 21 June 2018 at 22:24, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote: Hello,

The reason seems to be that the mechanism uses a “once” breakpoint which is for now implemented by removing the breakpoint at runtime. This leads to the debugger getting text/bytecode offset wrong as we install a different method.

runTest: testSelector of: testClass

| breakpoint | breakpoint := Breakpoint new node: (testClass lookupSelector: testSelector) ast; once; install. [super runTest: testSelector of: testClass] ensure: [ breakpoint remove ]

Thanks for the update.

I am thinking of implementing the once breakpoints using a condition instead (so that the byte code is unchanged). The other nice effect is that one can more easily re-enable those breakpoints (like haltOnce).

That sounds like a good idea. Will that change the semantics at all?

In the first step no… it would work like haltOnce now.

IIRC, prior to metalinks the Halt-once was a global reset only, and post metalinks it was reset by a method save. So will the condition-state be global or per method? And then mild curiousity about the implementation - how would that state be stored?

Im the first step I guess in the breakpoint object. For haltOnce: it does not really use MetaLinks, just AST annotations… I liked the simplicity and the fact that it would be “per statement” and not global. But what is bad is that we lose the state at recompile… it would be nice to fix that. Marcus