Fix for Issue #253 - Features: Disassembler, Cross-platform Disassembler, Cross-profiling settings dialog #14

dknysh · 2020-09-17T11:33:14Z

Hello Milian,

Could you please review and merge the changes for Issue #253 (KDAB/hotspot#253)?
Following our discussion about the features review and merge process I have separated the all changes into parts.

Thank you,
Darya

milianw

Hey!

Thanks for submitting the changes. Please rework the patch series though - the individual commit messages often don't seem to align at all to the actual changes within the commits.

Furthermore, do not bundle multiple changes within one commit. Split them apart please. Whenever you have a commit message that says:

Do A

And do B

Then this means your patch needs to be split into two. (Or three or four, if there are more and do X)

Furthermore, please rephrase your commit messages in such a way that they talk about the feature they are enabling. One example:

 Added coloring of incomplete callchains restricted by 'max-stack' opt…

…ion.

And callchains full unwind by context menu item on Bottom Up symbols.

Within the context of perfparser, the above commit message is really bad:

perfparser has no notion of colors, it's a CLI app without a GUI
dito for context menus

The above commit should rather have a text along the following lines:

Track unwinding completed the full callchain or stopped earlier

For now, this only covers the maxUnwindStack option. In the future
we also need to find a way to set this flag when unwinding failed
after exhausting the stack sample, or when the LBR buffer was too
small.

Please go through this series again and clean it up, taking the above into consideration.

Github's code review abilities are also really bad at larger series. So maybe it would be better if you hoist some changes out of this series and submit those in a separate merge request. E.g. the command line switches for verbose, max stack depth etc. are unrelated to the features that enable the disassemble viewer.

Thank you.

app/perfaddresscache.h

app/perfsymboltable.cpp

app/main.cpp

app/perfaddresscache.cpp

app/perfunwind.cpp

dknysh · 2020-09-21T09:56:36Z

Hey!

Thanks for submitting the changes. Please rework the patch series though - the individual commit messages often don't seem to align at all to the actual changes within the commits.

Milian, I have splitted into 9 parts the all changes (as it were committed historically splitting and joining commits) for hotspot and committed into 2 repositories simulteneously. Due to this commit messages are the same for both. I thought it is more convinient to split them into working pairs of commits.

milianw · 2020-09-21T15:26:38Z

Hey!
Thanks for submitting the changes. Please rework the patch series though - the individual commit messages often don't seem to align at all to the actual changes within the commits.

Milian, I have splitted into 9 parts the all changes (as it were committed historically splitting and joining commits) for hotspot and committed into 2 repositories simulteneously. Due to this commit messages are the same for both. I thought it is more convinient to split them into working pairs of commits.

I'm sorry, but it is not more convenient - actually quite the opposite. It makes it much harder to review the patches in isolation and will make it impossible to upstream them to Qt.

Please restructure this patch series as I indicated.

Thank you!

dknysh · 2020-09-23T05:14:55Z

Please restructure this patch series as I indicated.

Milian,
I have restructured and force pushed into features/nips branch -

dknysh · 2020-09-23T16:36:44Z

Github's code review abilities are also really bad at larger series. So maybe it would be better if you hoist some changes out of this series and submit those in a separate merge request. E.g. the command line switches for verbose, max stack depth etc. are unrelated to the features that enable the disassemble viewer.

Are you expecting this on me? Ok, I will prepare.

milianw · 2020-09-23T19:24:47Z

Github's code review abilities are also really bad at larger series. So maybe it would be better if you hoist some changes out of this series and submit those in a separate merge request. E.g. the command line switches for verbose, max stack depth etc. are unrelated to the features that enable the disassemble viewer.

Are you expecting this on me? Ok, I will prepare.

I would appreciate it, but this isn't required. I'm simply swamped by other work - I'll try to find some time for reviewing this tomorrow.

Thanks a lot for your work already!

app/main.cpp

app/perfsymboltable.cpp

app/perfaddresscache.h

app/perfsymboltable.cpp

app/perfaddresscache.h

app/perfsymboltable.cpp

app/main.cpp

app/perfaddresscache.cpp

app/perfunwind.cpp

dknysh · 2020-09-24T13:19:03Z

About demangling -
It is used in the first commit - 61be877 line 849 app/perfsymboltable.cpp. I need mangled 'symname' but they are all already demangled.

app/perfsymboltable.cpp

dknysh · 2020-09-25T04:41:33Z

As for examples - I use my small sample for experiments. I have attached it.
demo.txt

milianw · 2020-09-25T15:15:54Z

As for examples - I use my small sample for experiments. I have attached it.
demo.txt

OK, but that alone does not explain anything to me. What are the issues you are seeing with this? Sorry, but I still don't understand at all what the problem with LBR is...

dknysh · 2020-09-28T06:13:43Z

OK, but that alone does not explain anything to me. What are the issues you are seeing with this? Sorry, but I still don't understand at all what the problem with LBR is.

For the moment (without the changes) in resolveCallchain there is the 'break' from callchain traverse if it hasBranchStack.
And callchain for LBR in this case is looked only for branchStack.

branchStack does not contain the full required information about locations inside function/method.
We still should traverse at least first user frame from callchain.

The steps to reproduce on version without the changes:

g++ demo.cpp
perf record --call-graph lbr ./a.out
See values in perfunwind.cpp/resolveCallchain traversed through branchStack for functions 'f' and 'g' from demo.
Compare with values got with 'perf annotate'.
perf annotate f -i ./perf.data
perf annotate g -i ./perf.data

You will see that some locations from first user frame are not traversed by perfparser.

milianw · 2020-09-28T10:03:15Z

OK, but that alone does not explain anything to me. What are the issues you are seeing with this? Sorry, but I still don't understand at all what the problem with LBR is.

For the moment (without the changes) in resolveCallchain there is the 'break' from callchain traverse if it hasBranchStack.
And callchain for LBR in this case is looked only for branchStack.

branchStack does not contain the full required information about locations inside function/method.
We still should traverse at least first user frame from callchain.

The steps to reproduce on version without the changes:
1. g++ demo.cpp

2. perf record --call-graph lbr ./a.out

3. See values in perfunwind.cpp/resolveCallchain traversed through branchStack for functions 'f' and 'g' from demo.

4. Compare with values got with 'perf annotate'.
   perf annotate f -i ./perf.data
   perf annotate g -i ./perf.data
   You will see that some locations from first user frame are not traversed by perfparser.

Please show me the output you get and show exactly the output you are expecting. Most notably also explain why annotate needs to be looked at. Because I don't want to add debug output to perfparser just now, I just look at the callstacks themselves for now:

$ perf script -i ./perf.data
...
a.out 205348 350068.831775:     706164 cycles: 
            7ffbaef4cbb0 __random+0x0 (/usr/lib/libc-2.32.so)
            7ffbaef4d0a8 rand+0x8 (/usr/lib/libc-2.32.so)
            564569d848e4 g+0xb (/tmp/a.out)
            564569d84945 f+0x51 (/tmp/a.out)
            564569d84986 main+0x4 (/tmp/a.out)
            7ffbaef34150 __libc_start_main+0xf0 (/usr/lib/libc-2.32.so)
            564569d84808 _start+0x28 (/tmp/a.out)
...

VS

$ HOTSPOT_GENERATE_SCRIPT_OUTPUT=1 hotspot
...
a.out   205348  350068.831775307:       706164 cycles
        00007ffbaef4cbb0 __random (libc-2.32.so)
        00007ffbaef4d0a8 rand (libc-2.32.so)
        0000564569d848e4 g(int) (a.out)
        0000564569d84945 f() (a.out)
        0000564569d84986 main (a.out)
        00007ffbaef34150 __libc_start_main (libc-2.32.so)
        0000564569d84808 _start (a.out)

So both encounter g and f in the callstacks. Why would the annotate view be different then?!

dknysh · 2020-09-28T13:26:08Z

So both encounter g and f in the callstacks. Why would the annotate view be different then?!

I have generated on my lbr perf.data 3 files with output:

HOTSPOT_GENERATE_SCRIPT_OUTPUT=1 hotspot > hotspot_generate_script_output.txt (version without the changes)
perf annotate -f --no-source g -i perf.data --stdio > perf_annotate_output.txt
perf script -i ./perf.data > perf_script_output.txt

hotspot_generate_script_output.txt
perf_annotate_output.txt
perf_script_output.txt

As you can see 'perf annotate' shows events costs for g()+0xf and g+0x5.
There is no g()+0x5 in script output.
This is the difference.

milianw · 2020-09-28T15:06:35Z

So both encounter g and f in the callstacks. Why would the annotate view be different then?!

I have generated on my lbr perf.data 3 files with output:
1. HOTSPOT_GENERATE_SCRIPT_OUTPUT=1 hotspot > hotspot_generate_script_output.txt (version without the changes)

2. perf annotate -f --no-source g -i perf.data --stdio > perf_annotate_output.txt

3. perf script -i ./perf.data > perf_script_output.txt
hotspot_generate_script_output.txt
perf_annotate_output.txt
perf_script_output.txt

As you can see 'perf annotate' shows events costs for g()+0xf and g+0x5.
There is no g()+0x5 in script output.
This is the difference.

OK, I finally know what you are trying to fix here - please make sure to include all of this in the commit.

But I would suggest we first concentrate on the non-lbr case and then look at this in the future in a separate merge request. Most notably, please make sure to extend TestPerfData::testFiles such that it also covers the new data for the disassembler.

Then add your example file as a static compiled exe and show how it gets disassembled with --call-graph dwarf and how it gets disassembled with --call-graph lbr. Then a patch fixing behavior clearly shows what gets improved by the diff in the test expectation file.

When you get to that, please also explain how the branch stack encodes the per-instruction cost - that is not clear to me. Because so far, I was under the impression that perf annotates per sample, but apparently it somehow distributes that per-sample cost then across the LBR entries? If so, then we should take this also into account for our other views in hotspot to get a more detailed per-line cost attribution e.g.

But once again - please put that into a separate merge request - it has nothing to do with the disassembler feature on its own and is only a nice-to-have on top that brings better results for LBR.

dknysh · 2020-09-29T12:26:37Z

But once again - please put that into a separate merge request - it has nothing to do with the disassembler feature on its own and is only a nice-to-have on top that brings better results for LBR.

Ok. I have moved LBR events costs related part out the merge request.
I will send you separate merge request with the changes for LBR after you merge the change of this request.

As for testFiles - I have committed 'demo' application (binary built from demo.cpp) and its 'dwarf' and 'lbr' perf.data.
If I should generate there 'expected' outputs please let me know how could I get them.

app/perfsymboltable.cpp

app/perfaddresscache.h

app/perfsymboltable.cpp

milianw · 2020-09-30T20:12:35Z

app/perfaddresscache.h

@@ -42,12 +42,13 @@ class PerfAddressCache

    struct SymbolCacheEntry
    {
-        SymbolCacheEntry(quint64 offset = 0, quint64 value = 0, quint64 size = 0, const QByteArray &symname = {}, const QByteArray &mangledSymName = {})
+        SymbolCacheEntry(quint64 offset = 0, quint64 value = 0, quint64 size = 0, const QByteArray &symname = {}, const QByteArray &mangledSymName = {}, quint64 adjust = 0)


I wonder, this patch message sounds pretty generic and not directly related to the disassembler - I think this should be split off into a separate review request and then merged. ideally, can you write a test case for this too?

please also describe the issue that this is solving in the commit message. I believe it means we are computing wrong function location addresses for functions that are missing debug symbols? i.e. those where we don't find a cu die or sub program die?

The problem concerns kernel symbols from *.ko modules. The modules are relocated.
My test for this is perf.data recorded with sudo rights on 'coremark' test.

OK, so is it possible to create a test for this? Afaik a normal library is also getting relocated when compiled with PIE, no? So ideally we could even test this without kernel modules? I guess we simply never noticed this, as we don't use the addresses yet in the GUI consumers of the perfparser output. So if you'd output them in PerfParserTestClient::convertToText and then in a follow up patch apply this change, then we should hopefully see a difference?

Ok, I will try

app/perfsymboltable.cpp

app/main.cpp

tests/auto/perfdata/tst_perfdata.cpp

dknysh · 2020-10-02T07:46:24Z

I have updated the changes accordingly your remarks.

milianw · 2020-10-02T10:25:12Z

app/perfaddresscache.h

            , size(size)
            , symname(symname)
+            , mangledSymName(mangledSymName)


this is still including the mangled sym name - can we please first implement the demangler without that? As I said - in theory start address and end address is all we need for the disassembler. If more is needed for some corner cases, then we can think about adding that in the future, but it would at the very least require a proper explanation (which I still haven't seen).

app/perfaddresscache.h

app/perfsymboltable.cpp

dknysh · 2020-12-10T08:26:54Z

Milian, I am going to send these patches upstream for review to Ulf.
Should I wait till you merge them into KDAB? Or it is OK that they can be upstream to Qt Creator even before they will be merged into KDAB?

milianw · 2020-12-10T08:42:02Z

Yes please send them upstream, the sooner the better

dknysh · 2020-12-11T06:23:49Z

I was not able send upstream the whole seria of patches for one review due to oddity with Change-ID.
So I have sent the first and then I will send them one after another.
https://codereview.qt-project.org/c/qt-creator/perfparser/+/326745

milianw · 2020-12-11T09:25:19Z

I was not able send upstream the whole seria of patches for one review due to oddity with Change-ID.
So I have sent the first and then I will send them one after another.
https://codereview.qt-project.org/c/qt-creator/perfparser/+/326745

No, please send them all in one go as a patch series. To do that, you'll have to amend all your patches to add the change id to all of them, then you can push all for review as one patch set.

Generally, I can recommend using git review for that purpose.

Added start address and size into Symbol and their stream output. A disassembler can then use the relative address and size of a symbol to find the instructions that belong to a function.

It is equal to symbol start added by offset inside function. Disassembler can then use them to compute and show events costs locations within function by instructions. Added stream output.

It is required to compute proper addresses on ARM.

milianw · 2020-12-11T10:04:59Z

I haven't figured out why yet, but I have some perf.data files which go into an infinite loop with e356e83 - apparently the location id chain is circular:

     0.000 warning: unknown[unknown:0]: frames: 8
     0.000 warning: unknown[unknown:0]: handle frame 1
     0.000 warning: unknown[unknown:0]: Symbol{symbol=perf_event_exec, relAddr=18446744069414584337, size=0, binary=sched} 0
     0.000 warning: unknown[unknown:0]: new symbol: Symbol{symbol=perf_event_exec, relAddr=18446744069414584337, size=0, binary=sched}
     0.000 warning: unknown[unknown:0]: handle frame 0
     0.000 warning: unknown[unknown:0]: skip
     0.000 warning: unknown[unknown:0]: handle frame 0
     0.000 warning: unknown[unknown:0]: Symbol{symbol=perf_event_exec, relAddr=18446744069414584337, size=0, binary=sched} 0
     0.000 warning: unknown[unknown:0]: new symbol: Symbol{symbol=perf_event_exec, relAddr=18446744069414584337, size=0, binary=sched}
     0.000 warning: unknown[unknown:0]: handle frame 0
     0.000 warning: unknown[unknown:0]: Symbol{symbol=perf_event_exec, relAddr=18446744069414584337, size=0, binary=sched} 0
     0.000 warning: unknown[unknown:0]: new symbol: Symbol{symbol=perf_event_exec, relAddr=18446744069414584337, size=0, binary=sched}
     0.000 warning: unknown[unknown:0]: handle frame 0
     0.000 warning: unknown[unknown:0]: Symbol{symbol=perf_event_exec, relAddr=18446744069414584337, size=0, binary=sched} 0
     0.000 warning: unknown[unknown:0]: new symbol: Symbol{symbol=perf_event_exec, relAddr=18446744069414584337, size=0, binary=sched}
     0.000 warning: unknown[unknown:0]: handle frame 0
     0.000 warning: unknown[unknown:0]: Symbol{symbol=perf_event_exec, relAddr=18446744069414584337, size=0, binary=sched} 0
     0.000 warning: unknown[unknown:0]: new symbol: Symbol{symbol=perf_event_exec, relAddr=18446744069414584337, size=0, binary=sched}
... repeats ad infinitum

milianw · 2020-12-11T10:14:24Z

ah no, that was an exported perfparser file which is now incompatible, but we don't detect it and go into an infinite loop, I'll have to think about how to handle that.

dknysh · 2020-12-11T10:29:19Z

I was not able send upstream the whole seria of patches for one review due to oddity with Change-ID.
So I have sent the first and then I will send them one after another.
https://codereview.qt-project.org/c/qt-creator/perfparser/+/326745

No, please send them all in one go as a patch series. To do that, you'll have to amend all your patches to add the change id to all of them, then you can push all for review as one patch set.

Generally, I can recommend using git review for that purpose.

Ulf has already started review of the first patch. If you don't mind I will send upstream 3 next patches as one patch set to another review. Or do you want me to add patches to existing review 326745?

Actual file path can differ from perf recorded. Compute and pass it to hotspot through Symbol struct field actualPath. Change-Id: I1e04db9aa7152f30fa53ed2fe3305828195d64f0

milianw · 2020-12-11T10:52:48Z

app/perfsymboltable.cpp

    if (elf.isValid()) {
        binaryId = m_unwind->resolveString(elf.originalFileName);
        binaryPathId = m_unwind->resolveString(elf.originalPath);
+        actualPath = findFile(elf.originalPath, elf.originalFileName, {});


why is this needed, why can't you use elf.localFile ?

app/perfsymboltable.cpp

milianw · 2020-12-11T10:59:19Z

I was not able send upstream the whole seria of patches for one review due to oddity with Change-ID.
So I have sent the first and then I will send them one after another.
https://codereview.qt-project.org/c/qt-creator/perfparser/+/326745

No, please send them all in one go as a patch series. To do that, you'll have to amend all your patches to add the change id to all of them, then you can push all for review as one patch set.
Generally, I can recommend using git review for that purpose.

Ulf has already started review of the first patch. If you don't mind I will send upstream 3 next patches as one patch set to another review. Or do you want me to add patches to existing review 326745?

gerrit is patch-centric, adding new patches doesn't change the previous one - just make sure all are in the same topic then this can be properly reviewed

milianw · 2020-12-11T11:02:25Z

Can you please give me permission to force-push to your branch such that I can send my changes there?

dknysh · 2020-12-11T11:09:48Z

Added permission. Please try.

milianw · 2020-12-11T11:12:51Z

ok that works, can you please check my last patch, most notably the change to remove the call to findFile and replace it by elf.localFile - does this still work for you? I don't get why you searched for the file again

dknysh · 2020-12-11T11:32:39Z

ok that works, can you please check my last patch, most notably the change to remove the call to findFile and replace it by elf.localFile - does this still work for you? I don't get why you searched for the file again

dknysh · 2020-12-11T11:32:51Z

Yes, it works.

dknysh · 2020-12-11T12:35:38Z

gerrit is patch-centric, adding new patches doesn't change the previous one - just make sure all are in the same topic then this can be properly reviewed

Could you tell me please if all patches from patch set should have the same Change-ID?
And when I need modify patch from the existed review how can I push it to the same review?

milianw · 2020-12-11T12:38:42Z

gerrit is patch-centric, adding new patches doesn't change the previous one - just make sure all are in the same topic then this can be properly reviewed

Could you tell me please if all patches from patch set should have the same Change-ID?
And when I need modify patch from the existed review how can I push it to the same review?

No, each patch needs to have its own Change-Id - just use git review to setup the commit hook for you, then this is done automatically. After you amended your patch you just send it up for review again, e.g. using git review. Since the change id will be the same, the corresponding gerrit page will get updated.

dknysh · 2020-12-15T10:01:33Z

gerrit
Change-Id: I96709ca380d0e58cd5cf5a8cc87116147b2754d6
https://codereview.qt-project.org/c/qt-creator/perfparser/+/326745

Change-Id: Iba32e1764633d7ffc3f0f36088525ed7a3d1c9d0
https://codereview.qt-project.org/c/qt-creator/perfparser/+/326942

Change-Id: Ifc93375707507fff0fcc62e164133771e43bd4b5
https://codereview.qt-project.org/c/qt-creator/perfparser/+/326943

Change-Id: I556035234cbcffa42497bf02e225d63565e4a0bf
https://codereview.qt-project.org/c/qt-creator/perfparser/+/326945

In qt6 QHash is no longer iterator safe ==138723==ERROR: AddressSanitizer: heap-use-after-free on address 0x51b000035c68 at pc 0x5d085ec696b9 bp 0x7ffe43776e00 sp 0x7ffe43776df0 READ of size 8 at 0x51b000035c68 thread T0 #0 0x5d085ec696b8 in void qt_ptr_swap<QTypedArrayData<char> >(QTypedArrayData<char>*&, QTypedArrayData<char>*&) /usr/include/qt6/QtCore/qswap.h:31 #1 0x5d085ec67e4f in QArrayDataPointer<char>::swap(QArrayDataPointer<char>&) /usr/include/qt6/QtCore/qarraydatapointer.h:131 #2 0x5d085ec66e97 in QByteArray::swap(QByteArray&) /usr/include/qt6/QtCore/qbytearray.h:103 #3 0x5d085ec66da8 in QByteArray::operator=(QByteArray&&) /usr/include/qt6/QtCore/qbytearray.h:101 #4 0x5d085ef0ca5c in CuDieRangeMapping::dieName(Dwarf_Die*) /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfdwarfdiecache.cpp:364 #5 0x5d085ee36e7c in operator() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfsymboltable.cpp:768 #6 0x5d085ee39eea in PerfSymbolTable::lookupFrame(unsigned long, bool, bool*) /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfsymboltable.cpp:774 #7 0x5d085ed06ec5 in frameCallback /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfunwind.cpp:541 #8 0x75a7437f7b08 in dwfl_thread_getframes (/usr/lib/libdw.so.1+0x5bb08) (BuildId: 9b3f42d0dd4107f1cd947702b04157dad2a9069a) #9 0x75a7437f2eba (/usr/lib/libdw.so.1+0x56eba) (BuildId: 9b3f42d0dd4107f1cd947702b04157dad2a9069a) #10 0x75a7437f3f2b in dwfl_getthreads (/usr/lib/libdw.so.1+0x57f2b) (BuildId: 9b3f42d0dd4107f1cd947702b04157dad2a9069a) #11 0x75a7437f7e81 in dwfl_getthread_frames (/usr/lib/libdw.so.1+0x5be81) (BuildId: 9b3f42d0dd4107f1cd947702b04157dad2a9069a) #12 0x5d085ed07b21 in PerfUnwind::unwindStack() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfunwind.cpp:557 #13 0x5d085ed0d129 in PerfUnwind::analyze(PerfRecordSample const&) /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfunwind.cpp:744 #14 0x5d085ed1b65f in PerfUnwind::flushEventBuffer(unsigned int) /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfunwind.cpp:1115 #15 0x5d085ed164b1 in PerfUnwind::finishedRound() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfunwind.cpp:976 #16 0x5d085ecc2fe8 in PerfData::processEvents(QDataStream&) /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfdata.cpp:243 #17 0x5d085eccbdc2 in PerfData::doRead() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfdata.cpp:414 #18 0x5d085eccd6f3 in PerfData::read() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfdata.cpp:431 #19 0x5d085ebfa511 in operator() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/main.cpp:383 #20 0x5d085ebfd5c6 in operator() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/main.cpp:452 #21 0x5d085ec0b9b9 in call /usr/include/qt6/QtCore/qobjectdefs_impl.h:137 #22 0x5d085ec0b121 in call<QtPrivate::List<>, void> /usr/include/qt6/QtCore/qobjectdefs_impl.h:345 #23 0x5d085ec0aa1e in impl /usr/include/qt6/QtCore/qobjectdefs_impl.h:555 #24 0x75a7429a3456 (/usr/lib/libQt6Core.so.6+0x1a3456) (BuildId: 2dc7cac262eec1f545dffaf6727f87faf910fb09) #25 0x5d085ec33520 in PerfHeader::finished() /home/lieven/KDAB/hotspot/build-dev-asan-qt6/3rdparty/libhotspot-perfparser_autogen/6F7ISLN55V/moc_perfheader.cpp:234 #26 0x5d085ec5d91c in PerfHeader::read() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfheader.cpp:122 #27 0x5d085ec2f1b7 in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, void (PerfHeader::*)()>::call(void (PerfHeader::*)(), PerfHeader*, void**) /usr/include/qt6/QtCore/qobjectdefs_impl.h:145 #28 0x5d085ec2e24a in void QtPrivate::FunctionPointer<void (PerfHeader::*)()>::call<QtPrivate::List<>, void>(void (PerfHeader::*)(), PerfHeader*, void**) /usr/include/qt6/QtCore/qobjectdefs_impl.h:182 #29 0x5d085ec2bf91 in QtPrivate::QCallableObject<void (PerfHeader::*)(), QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) /usr/include/qt6/QtCore/qobjectdefs_impl.h:553 #30 0x75a74298d93e in QObject::event(QEvent*) (/usr/lib/libQt6Core.so.6+0x18d93e) (BuildId: 2dc7cac262eec1f545dffaf6727f87faf910fb09) #31 0x75a742945bc2 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (/usr/lib/libQt6Core.so.6+0x145bc2) (BuildId: 2dc7cac262eec1f545dffaf6727f87faf910fb09) #32 0x75a742945faa in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (/usr/lib/libQt6Core.so.6+0x145faa) (BuildId: 2dc7cac262eec1f545dffaf6727f87faf910fb09) #33 0x75a742babe4b (/usr/lib/libQt6Core.so.6+0x3abe4b) (BuildId: 2dc7cac262eec1f545dffaf6727f87faf910fb09) #34 0x75a740d13558 (/usr/lib/libglib-2.0.so.0+0x5d558) (BuildId: 7b781c8d1a6e2161838c5d8f3bd797797c132753) #35 0x75a740d76156 (/usr/lib/libglib-2.0.so.0+0xc0156) (BuildId: 7b781c8d1a6e2161838c5d8f3bd797797c132753) #36 0x75a740d12a54 in g_main_context_iteration (/usr/lib/libglib-2.0.so.0+0x5ca54) (BuildId: 7b781c8d1a6e2161838c5d8f3bd797797c132753) #37 0x75a742ba985c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (/usr/lib/libQt6Core.so.6+0x3a985c) (BuildId: 2dc7cac262eec1f545dffaf6727f87faf910fb09) #38 0x75a742950105 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (/usr/lib/libQt6Core.so.6+0x150105) (BuildId: 2dc7cac262eec1f545dffaf6727f87faf910fb09) #39 0x75a74294a27c in QCoreApplication::exec() (/usr/lib/libQt6Core.so.6+0x14a27c) (BuildId: 2dc7cac262eec1f545dffaf6727f87faf910fb09) #40 0x5d085ec04e44 in main /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/main.cpp:481 #41 0x75a741a34e07 (/usr/lib/libc.so.6+0x25e07) (BuildId: 98b3d8e0b8c534c769cb871c438b4f8f3a8e4bf3) #42 0x75a741a34ecb in __libc_start_main (/usr/lib/libc.so.6+0x25ecb) (BuildId: 98b3d8e0b8c534c769cb871c438b4f8f3a8e4bf3) #43 0x5d085ebf4b64 in _start (/home/lieven/KDAB/hotspot/build-dev-asan-qt6/libexec/hotspot-perfparser+0x72db64) (BuildId: 580374afdfc7f3994c76369459f6848384c3c771) 0x51b000035c68 is located 1512 bytes inside of 1536-byte region [0x51b000035680,0x51b000035c80) freed by thread T0 here: #0 0x75a7430ff22a in operator delete[](void*) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:155 #1 0x5d085ef2c5af in QHashPrivate::Span<QHashPrivate::Node<unsigned long, QByteArray> >::addStorage() /usr/include/qt6/QtCore/qhash.h:409 #2 0x5d085ef240f5 in QHashPrivate::Span<QHashPrivate::Node<unsigned long, QByteArray> >::insert(unsigned long) /usr/include/qt6/QtCore/qhash.h:283 #3 0x5d085ef1d324 in QHashPrivate::Data<QHashPrivate::Node<unsigned long, QByteArray> >::Bucket::insert() const /usr/include/qt6/QtCore/qhash.h:511 #4 0x5d085ef18c64 in QHashPrivate::Data<QHashPrivate::Node<unsigned long, QByteArray> >::findOrInsert(unsigned long const&) /usr/include/qt6/QtCore/qhash.h:728 #5 0x5d085ef1551a in QHash<unsigned long, QByteArray>::operator[](unsigned long const&) /usr/include/qt6/QtCore/qhash.h:1064 #6 0x5d085ef08e30 in prependScopeNames(QByteArray&, Dwarf_Die*, QHash<unsigned long, QByteArray>&) /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfdwarfdiecache.cpp:204 #7 0x5d085ef0965b in qualifiedDieName(Dwarf_Die*, QHash<unsigned long, QByteArray>&) /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfdwarfdiecache.cpp:229 #8 0x5d085ef0c9b8 in CuDieRangeMapping::dieName(Dwarf_Die*) /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfdwarfdiecache.cpp:364 #9 0x5d085ee36e7c in operator() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfsymboltable.cpp:768 #10 0x5d085ee39eea in PerfSymbolTable::lookupFrame(unsigned long, bool, bool*) /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfsymboltable.cpp:774 #11 0x5d085ed06ec5 in frameCallback /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfunwind.cpp:541 #12 0x75a7437f7b08 in dwfl_thread_getframes (/usr/lib/libdw.so.1+0x5bb08) (BuildId: 9b3f42d0dd4107f1cd947702b04157dad2a9069a) #13 0x75a7437f2eba (/usr/lib/libdw.so.1+0x56eba) (BuildId: 9b3f42d0dd4107f1cd947702b04157dad2a9069a) #14 0x75a7437f3f2b in dwfl_getthreads (/usr/lib/libdw.so.1+0x57f2b) (BuildId: 9b3f42d0dd4107f1cd947702b04157dad2a9069a) #15 0x75a7437f7e81 in dwfl_getthread_frames (/usr/lib/libdw.so.1+0x5be81) (BuildId: 9b3f42d0dd4107f1cd947702b04157dad2a9069a) #16 0x5d085ed07b21 in PerfUnwind::unwindStack() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfunwind.cpp:557 #17 0x5d085ed0d129 in PerfUnwind::analyze(PerfRecordSample const&) /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfunwind.cpp:744 #18 0x5d085ed1b65f in PerfUnwind::flushEventBuffer(unsigned int) /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfunwind.cpp:1115 #19 0x5d085ed164b1 in PerfUnwind::finishedRound() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfunwind.cpp:976 #20 0x5d085ecc2fe8 in PerfData::processEvents(QDataStream&) /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfdata.cpp:243 #21 0x5d085eccbdc2 in PerfData::doRead() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfdata.cpp:414 #22 0x5d085eccd6f3 in PerfData::read() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfdata.cpp:431 #23 0x5d085ebfa511 in operator() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/main.cpp:383 #24 0x5d085ebfd5c6 in operator() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/main.cpp:452 #25 0x5d085ec0b9b9 in call /usr/include/qt6/QtCore/qobjectdefs_impl.h:137 #26 0x5d085ec0b121 in call<QtPrivate::List<>, void> /usr/include/qt6/QtCore/qobjectdefs_impl.h:345 #27 0x5d085ec0aa1e in impl /usr/include/qt6/QtCore/qobjectdefs_impl.h:555 #28 0x75a7429a3456 (/usr/lib/libQt6Core.so.6+0x1a3456) (BuildId: 2dc7cac262eec1f545dffaf6727f87faf910fb09) #29 0x5d085ec33520 in PerfHeader::finished() /home/lieven/KDAB/hotspot/build-dev-asan-qt6/3rdparty/libhotspot-perfparser_autogen/6F7ISLN55V/moc_perfheader.cpp:234 previously allocated by thread T0 here: #0 0x75a7430fe682 in operator new[](unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:98 #1 0x5d085ef2c181 in QHashPrivate::Span<QHashPrivate::Node<unsigned long, QByteArray> >::addStorage() /usr/include/qt6/QtCore/qhash.h:394 #2 0x5d085ef240f5 in QHashPrivate::Span<QHashPrivate::Node<unsigned long, QByteArray> >::insert(unsigned long) /usr/include/qt6/QtCore/qhash.h:283 #3 0x5d085ef1d324 in QHashPrivate::Data<QHashPrivate::Node<unsigned long, QByteArray> >::Bucket::insert() const /usr/include/qt6/QtCore/qhash.h:511 #4 0x5d085ef18c64 in QHashPrivate::Data<QHashPrivate::Node<unsigned long, QByteArray> >::findOrInsert(unsigned long const&) /usr/include/qt6/QtCore/qhash.h:728 #5 0x5d085ef1551a in QHash<unsigned long, QByteArray>::operator[](unsigned long const&) /usr/include/qt6/QtCore/qhash.h:1064 #6 0x5d085ef0c883 in CuDieRangeMapping::dieName(Dwarf_Die*) /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfdwarfdiecache.cpp:362 #7 0x5d085ee36e7c in operator() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfsymboltable.cpp:768 #8 0x5d085ee39eea in PerfSymbolTable::lookupFrame(unsigned long, bool, bool*) /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfsymboltable.cpp:774 #9 0x5d085ed06ec5 in frameCallback /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfunwind.cpp:541 #10 0x75a7437f7b08 in dwfl_thread_getframes (/usr/lib/libdw.so.1+0x5bb08) (BuildId: 9b3f42d0dd4107f1cd947702b04157dad2a9069a) #11 0x75a7437f2eba (/usr/lib/libdw.so.1+0x56eba) (BuildId: 9b3f42d0dd4107f1cd947702b04157dad2a9069a) #12 0x75a7437f3f2b in dwfl_getthreads (/usr/lib/libdw.so.1+0x57f2b) (BuildId: 9b3f42d0dd4107f1cd947702b04157dad2a9069a) #13 0x75a7437f7e81 in dwfl_getthread_frames (/usr/lib/libdw.so.1+0x5be81) (BuildId: 9b3f42d0dd4107f1cd947702b04157dad2a9069a) #14 0x5d085ed07b21 in PerfUnwind::unwindStack() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfunwind.cpp:557 #15 0x5d085ed0d129 in PerfUnwind::analyze(PerfRecordSample const&) /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfunwind.cpp:744 #16 0x5d085ed1b65f in PerfUnwind::flushEventBuffer(unsigned int) /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfunwind.cpp:1115 #17 0x5d085ed164b1 in PerfUnwind::finishedRound() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfunwind.cpp:976 #18 0x5d085ecc2fe8 in PerfData::processEvents(QDataStream&) /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfdata.cpp:243 #19 0x5d085eccbdc2 in PerfData::doRead() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfdata.cpp:414 #20 0x5d085eccd6f3 in PerfData::read() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfdata.cpp:431 #21 0x5d085ebfa511 in operator() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/main.cpp:383 #22 0x5d085ebfd5c6 in operator() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/main.cpp:452 #23 0x5d085ec0b9b9 in call /usr/include/qt6/QtCore/qobjectdefs_impl.h:137 #24 0x5d085ec0b121 in call<QtPrivate::List<>, void> /usr/include/qt6/QtCore/qobjectdefs_impl.h:345 #25 0x5d085ec0aa1e in impl /usr/include/qt6/QtCore/qobjectdefs_impl.h:555 #26 0x75a7429a3456 (/usr/lib/libQt6Core.so.6+0x1a3456) (BuildId: 2dc7cac262eec1f545dffaf6727f87faf910fb09) #27 0x5d085ec33520 in PerfHeader::finished() /home/lieven/KDAB/hotspot/build-dev-asan-qt6/3rdparty/libhotspot-perfparser_autogen/6F7ISLN55V/moc_perfheader.cpp:234 #28 0x5d085ec5d91c in PerfHeader::read() /home/lieven/KDAB/hotspot/3rdparty/perfparser/app/perfheader.cpp:122 #29 0x5d085ec2f1b7 in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, void (PerfHeader::*)()>::call(void (PerfHeader::*)(), PerfHeader*, void**) /usr/include/qt6/QtCore/qobjectdefs_impl.h:145 SUMMARY: AddressSanitizer: heap-use-after-free /usr/include/qt6/QtCore/qswap.h:31 in void qt_ptr_swap<QTypedArrayData<char> >(QTypedArrayData<char>*&, QTypedArrayData<char>*&) Shadow bytes around the buggy address: 0x51b000035980: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x51b000035a00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x51b000035a80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x51b000035b00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x51b000035b80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd =>0x51b000035c00: fd fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd 0x51b000035c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x51b000035d00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x51b000035d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x51b000035e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x51b000035e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==138723==ABORTING

dknysh changed the title ~~Features/nips~~ Fix for Issue #253 - Features: Disassembler, Cross-platform Disassembler, Cross-profiling settings dialog Sep 17, 2020

milianw requested changes Sep 21, 2020

View reviewed changes

dknysh force-pushed the features/nips branch from acdbde5 to dafcf22 Compare September 24, 2020 04:36

milianw reviewed Sep 24, 2020

View reviewed changes

app/main.cpp Outdated Show resolved Hide resolved

milianw reviewed Sep 24, 2020

View reviewed changes

app/main.cpp Outdated Show resolved Hide resolved

milianw requested changes Sep 24, 2020

View reviewed changes

app/main.cpp Outdated Show resolved Hide resolved

app/main.cpp Outdated Show resolved Hide resolved

app/perfaddresscache.cpp Outdated Show resolved Hide resolved

app/perfunwind.cpp Outdated Show resolved Hide resolved

milianw reviewed Sep 24, 2020

View reviewed changes

app/perfsymboltable.cpp Outdated Show resolved Hide resolved

milianw force-pushed the hotspot branch from 60a3b3c to 80f3c62 Compare September 25, 2020 12:24

dknysh force-pushed the features/nips branch from dafcf22 to ba875bb Compare September 28, 2020 04:52

milianw closed this Sep 28, 2020

milianw reopened this Sep 28, 2020

dknysh force-pushed the features/nips branch from ba875bb to acde3c2 Compare September 29, 2020 12:01

milianw requested changes Sep 30, 2020

View reviewed changes

dknysh force-pushed the features/nips branch from acde3c2 to 09a05d3 Compare October 2, 2020 07:39

milianw requested changes Oct 2, 2020

View reviewed changes

milianw reviewed Oct 29, 2020

View reviewed changes

app/perfsymboltable.cpp Show resolved Hide resolved

dknysh added 3 commits December 11, 2020 10:32

Added Disassembler functionality.

fccac7c

Added start address and size into Symbol and their stream output. A disassembler can then use the relative address and size of a symbol to find the instructions that belong to a function.

Added location's relative address computation.

336279c

It is equal to symbol start added by offset inside function. Disassembler can then use them to compute and show events costs locations within function by instructions. Added stream output.

Added alignment for ARM addresses.

501cd6b

It is required to compute proper addresses on ARM.

Added actual file path computation for symbols.

1c1dc94

Actual file path can differ from perf recorded. Compute and pass it to hotspot through Symbol struct field actualPath. Change-Id: I1e04db9aa7152f30fa53ed2fe3305828195d64f0

milianw requested changes Dec 11, 2020

View reviewed changes

milianw force-pushed the features/nips branch from 7a36ded to 1c1dc94 Compare December 11, 2020 11:11

milianw merged commit 1c1dc94 into KDAB:hotspot Dec 11, 2020

dknysh mentioned this pull request Mar 2, 2021

LBR unwinding method processing enhancement for Disassembly. #18

Merged

lievenhey mentioned this pull request Oct 11, 2024

feat: fix crash in qt6 #35

Merged

Fix for Issue #253 - Features: Disassembler, Cross-platform Disassembler, Cross-profiling settings dialog #14

Fix for Issue #253 - Features: Disassembler, Cross-platform Disassembler, Cross-profiling settings dialog #14

Conversation

dknysh commented Sep 17, 2020 • edited Loading

milianw left a comment

Choose a reason for hiding this comment

dknysh commented Sep 21, 2020 • edited Loading

milianw commented Sep 21, 2020

dknysh commented Sep 23, 2020 • edited Loading

dknysh commented Sep 23, 2020

milianw commented Sep 23, 2020

dknysh commented Sep 24, 2020 • edited Loading

dknysh commented Sep 25, 2020 • edited Loading

milianw commented Sep 25, 2020

dknysh commented Sep 28, 2020

milianw commented Sep 28, 2020 • edited Loading

dknysh commented Sep 28, 2020 • edited Loading

milianw commented Sep 28, 2020

dknysh commented Sep 29, 2020

milianw Sep 30, 2020

Choose a reason for hiding this comment

dknysh Oct 1, 2020

Choose a reason for hiding this comment

milianw Oct 1, 2020

Choose a reason for hiding this comment

dknysh Oct 1, 2020

Choose a reason for hiding this comment

dknysh commented Oct 2, 2020

milianw Oct 2, 2020

Choose a reason for hiding this comment

dknysh commented Dec 10, 2020

milianw commented Dec 10, 2020

dknysh commented Dec 11, 2020

milianw commented Dec 11, 2020

milianw commented Dec 11, 2020

milianw commented Dec 11, 2020

dknysh commented Dec 11, 2020 • edited Loading

milianw Dec 11, 2020

Choose a reason for hiding this comment

milianw commented Dec 11, 2020

milianw commented Dec 11, 2020

dknysh commented Dec 11, 2020

milianw commented Dec 11, 2020

dknysh commented Dec 11, 2020

dknysh commented Dec 11, 2020

dknysh commented Dec 11, 2020

milianw commented Dec 11, 2020

dknysh commented Dec 15, 2020

dknysh commented Sep 17, 2020 •

edited

Loading

dknysh commented Sep 21, 2020 •

edited

Loading

dknysh commented Sep 23, 2020 •

edited

Loading

dknysh commented Sep 24, 2020 •

edited

Loading

dknysh commented Sep 25, 2020 •

edited

Loading

milianw commented Sep 28, 2020 •

edited

Loading

dknysh commented Sep 28, 2020 •

edited

Loading

dknysh commented Dec 11, 2020 •

edited

Loading