Hi all!

I rarely discovered that much errors with one single command :-)

Steps to reproduce

Print it:

(ObjectTracer on: true) ifTrue: [1]

Expected behavior

It is printed: 1

Actual behavior

The following tracer notifications appear (proceed them all):

  1.  (3x) #printStringLimitedTo:, #longPrintOn:limitedTo:indent: and again #printStringLimitedTo:, caused by SmalltalkImage >> #logSqueakError:inContext:
  2.  #mustBeBoolean
  3.  (3 more print message called by #logSqueakError:inContext: again, see the next error)
  4.  Error: Where's the jump?
Caused by #mustBeBooleanIn:, #skipBackBeforeJump

If you still keep proceeding:

  1.  (3 more print message called by #logSqueakError:inContext: again, see the next error)
  2.  Finally, the NonBooleanReceiver error from 2.
  3.  VM crashes.

Summarizing the bugs
ObjectTracer traces too much

The amount of messages printed by the ObjectTracer is an unintended side effect of the way it signals calls via the debugger. The debugger logs this error, including the stack trace. How can we avoid this? Should we suppress all further notifications from one ObjectTracer instance during the first one is debugged?

#mustBeBoolean is sent to boolean proxy

This is caused by the simulation of the inlined #ifTrue: call.
I don't know whether this is worth to be fixed before Scorch?
If yes, I think we would need to disable inlining for this particular selector or make inlining opt-out-able as proposed here (this would probably be way too slow)<http://forum.world.st/The-Inbox-HelpSystem-Core-ct-123-mcz-tp5105402p5113636.html>.

#mustBoBoolean depends on caller chain

It turns out that #mustBeBoolean relies on being called from a context that just did a jump. This makes it impossible to forward this message as usual via a transparent proxy/decorator.

We use this pattern in other methods as well. How can we enable transparent wrappers not to collide with method contexts depending on their sender?

Best,

Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200325/76d1ee0a/attachment.html>