Disassembly displays old source (caching issue?) and search is broken

[GitMensch]

trafficstars

Describe the bug Use of Disassembly shows partially (and not always) the source of a previous disassembly. Furthermore the search function seems to be totally broken.

@lievenhey I guess you can reproduce and want to have a look at this. Search definitely worked in older appimages and "caching atifacts" also seem to be a new thing.

[milianw]

how do you trigger this? can you give more detailed information please?

[GitMensch]

just retested with today's appimage

• open disassembly of a bigger function in source1
• open disassembly of a function in source2

result: you mostly see the source of source1, instead of source2, but the title is set to and the syntax language is used according to source2 and the number of lines is limited to the lines of the function in source2

[lievenhey]

Just to make sure, you are using the correct version of your executable? Disassembler works with addresses not and dwarf information. In theory a compiler can generate two different binaries for the same source code. Depending if he reorders the binary or not (used in obfuscated code to make leaked debug infos unusable).

I sometimes encounter a similar problem after a compiler change / update.

[GitMensch]

Sometimes the binaries are out of date, often just recompiled. If there are differences then the counters are off by some lines (or plain wrong when the code around it changed).

But this is about totally showing the wrong source, and this is "new" and happens since the last big Disassembly overhaul.

[milianw]

also: for the situation you describe @lievenhey we should ideally catch it and noisily show a warning to the user. we can detect it by comparing buildids.

[GitMensch]

I guess you cannot reproduce that with the appimage? Is that related to QT_QPA_PLATFORM as in #339?

Do we need something like an explicit update call to also change the content of the lines?

[lievenhey]

Ah, found it (actually @milianw but in another context). In HighlightedText::setText the QVector is reset correctly. This causes the weird behaviour you are seeing.

[milianw]

@GitMensch wrote:

At least with the new approach-the problem persists. I can now reproduce: disassembly shown, then showing a different disassembly - the code pane was adjusted to show other code, but the code lines shown mismatches the cycles and the disassembly. If I restart hotspot and show the disassembly of that other function "directly" then there's a perfect match.

I suggest to reopen the originating issue....