commenting in disassembly breaks decompilation

[psifertex]

Environment information

• Operating System: 10.14.6

• Cutter version: Version 1.9.0
  Using r2-3.8.0
  Based on Qt 5.12.1 (Clang 10.0 (Apple), 64 bit)

• File format: ELF, but doesn't look like an elf specific bug.

Describe the bug

Adding comments in disassembly (and maybe even to source I've just tested that less) frequently breaks decompilation, though exactly how it breaks appears inconsistent (maybe dependent on the comment content or length?)

To Reproduce

Steps to reproduce the behavior:

1. Open any file (In the screenshot I'm using "bomb" from: http://csapp.cs.cmu.edu/3e/bomb.tar but I've tested other files with similar results) with default Cutter 1.9 settings
2. Enable disassembly graph
3. Click on main
4. Start adding comments
5. Decompilation becomes corrupted

Expected behavior

Decompilation is not corrupted but rather shows comments in the appropriate location, or not at all.

Screenshots

In this screenshot, the first comment actually adds a "bad opcode" to the decompilation but the second comment /really/ breaks the output.

[psifertex]

As an aside, one of the times I was testing this while recording I actually got a crash though I haven't been able to reproduce it yet, even following what I thought was the exact same steps. In fact it looks non-deterministic because adding the same comment at the same location sometimes produces different results in the decompilation instruction.

I'll try to do it again under a debugger though I do have the screen recording so you can see it happening. I'll file a separate bug if I'm able to reproduce or get more info, just noting it here in case any likely crashing candidates come up while investigating this one.

I'd rather not share the minidump for some privacy reasons, but happy to extract some info from it if there's specific questions I can answer, but it seems quite likely that the root cause of this bug will likely fix that as well.

[psifertex]

Sorry, editing the image made it too big, re-uploaded:

[ITAYC0HEN]

Thank you for a VERY important issue. This crash is something we will investigate as soon as we can. Thanks!

[thestr4ng3r]

I can reproduce this issue with the Cutter Release on macOS, but it seems to be already fixed by 0a2cbda. I can reproduce it quite reliably before the commit, but not after it.

About the crash, I am quite sure it is the same issue too, but just to be sure it would be good if you could extract a stacktrace from it. To do so, clone https://chromium.googlesource.com/breakpad/breakpad, ./configure && make, then run
src/processor/minidump_stackwalk ~/Cutter_crash_dump_<...>.dmp symbols
with symbols being the folder from here:
cutter-v1.9.0-macos-symbols.tar.gz

[psifertex]

Stack trace attached.
stacktrace.txt

[thestr4ng3r]

Ok, the stacktrace doesn't say too much, but it's most likely that it is the same issue. Thanks!