These bytecodes are notably encountered via messages such as ifTrue: and ifFalse:.
If you debug this:
| a |
a := 2.
a = 2 ifTrue: [ a := 3 ].
a := 4.
and if you try to skipUpTo after the ifTrue: message (for example, before a:=4), the image will actually freeze:
This is because, when it tries to skipUpTo this node, it skips the a = 2 message node and puts the value of a on the stack instead of a boolean. Then, the skip command tries to step to the first interesting bytecode. And, actually, the jumpIfFalse: bytecode that is associated to the ifTrue: message is stepped because it is considered as a non-interesting bytecode. The skip command does that to keep the right number of elements there should be on the stack. However this bytecode expects to find a boolean on the stack, which is not the case because the comparison has been skipped. So an exception occurs, which changes the suspended context and this is not handled.
By the way, in this case, the process in sindarin debugger is updated with the right suspended context (the one from the exception) BUT: the process in the debug session from the sindarin debugger is updated but not the interrupted context in this process, which looks super weird to me.
These bytecodes are notably encountered via messages such as
ifTrue:andifFalse:.If you debug this:
and if you try to skipUpTo after the ifTrue: message (for example, before a:=4), the image will actually freeze:
This is because, when it tries to skipUpTo this node, it skips the a = 2 message node and puts the value of a on the stack instead of a boolean. Then, the skip command tries to step to the first interesting bytecode. And, actually, the
jumpIfFalse:bytecode that is associated to theifTrue:message is stepped because it is considered as a non-interesting bytecode. The skip command does that to keep the right number of elements there should be on the stack. However this bytecode expects to find a boolean on the stack, which is not the case because the comparison has been skipped. So an exception occurs, which changes the suspended context and this is not handled.By the way, in this case, the process in sindarin debugger is updated with the right suspended context (the one from the exception) BUT: the process in the debug session from the sindarin debugger is updated but not the interrupted context in this process, which looks super weird to me.