LBR unwinding method processing enhancement for Disassembly. by dknysh · Pull Request #18 · KDAB/perfparser

dknysh · 2021-03-02T05:00:26Z

Hello, Milian.

Could you please review the changes to add LBR unwinding method proper processing for Disassembly.

Earlier we have been starting to discuss the issue:
#14 (comment)

There are some required frames are not looked up for LBR unwinding method.
Entered additional disasmFrames to accumulate frames for LBR
to compute then Disassembly events costs within function/method.

Thank you,
Darya

milianw

hey, sorry for the delay. please explain why this is needed, and why we need different frame storage. also please add a testcase somehow, i.e. run perf with lbr on one of the existing static example binaries and try to reproduce it that way

milianw · 2021-03-14T19:37:48Z

app/perfunwind.cpp

+        int frame = symbols->lookupFrame(ip, isKernel, &m_currentUnwind.isInterworking);
+        // There are some required frames are not looked up for LBR unwinding method.
+        // Entered disasmFrames to accumulate frames for LBR to compute then Disassembly events costs within function/method.
+        if (branchStack) {


as I mentioned in the past - I do not understand why we have to distinguish between disasm frames and non-disasm frames. a frame is a frame, either it applies to all views or none.

please expand your commit message with an example that shows why this is needed.

dknysh · 2021-03-17T07:58:44Z

Hello, Milian.
I have updated source code and generated the similar logs for perf.lbr.data recorded with LBR on perfdata/vector_static_gcc/vector_static_gcc_v9.1.0.

hotspot_generate_script_output.txt
hotspot_generate_script_output_prev.txt
perf_annotate_output.txt
perf_script_output.txt

I also attach diff with current KDAB to show the issue - for example, 0x41b477 __hypot_finite that is missed on version without presented patch.
diff hotspot_generate_script_output.txt hotspot_generate_script_output_prev.txt
hypot_finite.diff.txt

Could you please review?

milianw · 2021-03-17T09:41:08Z

Thanks for the files, that is very helpful. Thing is, I'm not convinced at all that this is something we need to change.

Please compare these snippets:

hotspot_generate_script_output_prev.txt:

vector_static_g	3509027	7037283.204239728:	930396 cycles
	000000000041b3b0 __hypot_finite (vector_static_gcc_v9.1.0)
	0000000000417a53 hypot (vector_static_gcc_v9.1.0)

hotspot_generate_script_output.txt:

vector_static_g	3509027	7037283.204239728:	930396 cycles
	000000000041b3b0 __hypot_finite (vector_static_gcc_v9.1.0)
	000000000041b3b4 __hypot_finite (vector_static_gcc_v9.1.0)
	000000000041b3b0 __hypot_finite (vector_static_gcc_v9.1.0)
	0000000000417a53 hypot (vector_static_gcc_v9.1.0)

This actually duplicates the address 41b3b0 which is very odd. Is this a jump/loop in the code that is recorded this way?

perf_script_output.txt:

vector_static_g 3509027 7037283.204239:     930396 cycles: 
	          41b3b0 __ieee754_hypot+0x0 (/home/dknysh/kdab-disasm-fraames/hotspot/3rdparty/perfparser/tests/auto/perfdata/vector_static_gcc/vector_static_gcc_v9.1.0)
	          417a53 __hypot+0x13 (/home/dknysh/kdab-disasm-fraames/hotspot/3rdparty/perfparser/tests/auto/perfdata/vector_static_gcc/vector_static_gcc_v9.1.0)

Note how this actually matches the _prev output above, so imo that's what we should keep.

grep 41b3b4 perf_annotate_output.txt:

    0.00 :   41b3b4:       push   %r13

So as we can see here, even perf annotate doesn't associate any cost with this address that we are supposedly missing.

Once again: I'm not convinced about this patch at all. Please explain why you think we should include it.

Now let's look at the address that you are pointing out:

hotspot_generate_script_output_prev.txt:

vector_static_g	3509027	7037283.210067432:	720467 cycles
	000000000041b3b0 __hypot_finite (vector_static_gcc_v9.1.0)
	0000000000417a53 hypot (vector_static_gcc_v9.1.0)

hotspot_generate_script_output.txt:

vector_static_g	3509027	7037283.210067432:	720467 cycles
	000000000041b477 __hypot_finite (vector_static_gcc_v9.1.0)
	000000000041b47f __hypot_finite (vector_static_gcc_v9.1.0)
	000000000041b3b0 __hypot_finite (vector_static_gcc_v9.1.0)

OK, no duplication in this case - quite the contrary, it actually looks like we are using the wrong address for the final sample location, i.e. the frame points at 0x41b3b0. With this patch it now points at 0x41b477.

perf_script_output.txt:

vector_static_g 3509027 7037283.210067:     720467 cycles: 
	          41b3b0 __ieee754_hypot+0x0 (/home/dknysh/kdab-disasm-fraames/hotspot/3rdparty/perfparser/tests/auto/perfdata/vector_static_gcc/vector_static_gcc_v9.1.0)
	          417a53 __hypot+0x13 (/home/dknysh/kdab-disasm-fraames/hotspot/3rdparty/perfparser/tests/auto/perfdata/vector_static_gcc/vector_static_gcc_v9.1.0)

Hm but it looks like perf script also points at 41b3b0 like we are doing...

grep -E "41b3b0|41b477|41b47f" perf_annotate_output.txt:

   17.26 :   41b3b0:       endbr64
   13.36 :   41b477:       xorpd  0x7f051(%rip),%xmm3        # 49a4d0 <conversion_rate+0xb8>
    0.00 :   41b47f:       movq   %rdx,%xmm4

So this is odd indeed, but note how 41b47f still has a cost of 0 - so adding that one to the list of locations is apparently wrong. I believe there's something else going on here that isn't understood properly yet. Please look into this in more detail and explain what perf annotate is doing compared to perf state, then put that knowledge into the commit message.

dknysh · 2021-03-17T10:02:10Z

I am adding 2 additional frames from callchain to branchStack.
I guess we should expect non-zero costs for the first - the deepest.
But if condition for the first - (!addedUserFrames... does not work, the second will be added.

Indeed when we the traverse frames then in hotspot part we look only the first and consider its symbol as visited after seeing.
The only I can suggest - to move that check and 'break' one frame upper and add 1 additional frame instead of 2.

milianw · 2021-03-17T20:37:53Z

I am adding 2 additional frames from callchain to branchStack.
I guess we should expect non-zero costs for the first - the deepest.
But if condition for the first - (!addedUserFrames... does not work, the second will be added.

I'm sorry, but this just says that you (and me too!) don't understand what's going on here. Blindly changing the code just to say "here, looks better" without understanding the background is not something that I find acceptable. If you care about fixing this situation, please investigate what the reason is, then lay out the explanation in the fix.

Are we misunderstanding the LBR chain? If so why and how? Can you link to references in the perf code upstream?

Indeed when we the traverse frames then in hotspot part we look only the first and consider its symbol as visited after seeing.

Yes, and that is correct for the purpose of hotspot's other views from what I can see. Note how we agree with perf stat from what I can see, so that part seems to be correct. But I'm totally unsure if it's only the raw annotation view that is affected. If the LBR chain somehow allows us to distribute the cost of a sample across multiple addresses, e.g. for jumps in loops or similar, then this would also apply to the per-line cost map.

The only I can suggest - to move that check and 'break' one frame upper and add 1 additional frame instead of 2.

No that is not sufficient. Please try to understand what is going on here and then get back with an explanation.

There are some required frames not looked up for LBR unwinding method. Added traversal the deepest frames for LBR by callchain to compute then Disassembly events costs within function/method properly. Added test into perfdata/vector_static_gcc for perf.lbr.data recorded with LBR.

dknysh · 2021-03-18T12:35:05Z

Are we misunderstanding the LBR chain? If so why and how? Can you link to references in the perf code upstream?

Previously I have tried to compare perfparser's LBR branchStack bypass and algorithm with perf sources (https://github.com/torvalds/linux/blob/master/tools/perf/util/machine.c - resolve_lbr_callchain_sample).
But I did not find any suspicious.
perfparser traversal of lbr branchStack does quite the same.
(Except that lbr_callchain_add_stitched_lbr_ip for the moment)

The only I can suggest - to move that check and 'break' one frame upper and add 1 additional frame instead of 2.

No that is not sufficient. Please try to understand what is going on here and then get back with an explanation.

My explanation is the following -
there is the difference for the first element of lbr branchStack - only its entry.to we reportIp.
And it is the deepest callee.
For the other we look only entry.from - caller.
According to the logs and debugger it (that entry.to) points to the start of that deepest callee - __hypot_finite + 0x0.
Probably we should not expect from lbr branchStack more exact address inside that callee but we still need it for Disassembly costs. It is the reason why I wanted to accumulate them into separate frames list.

Then I can suppose that condition
// sometimes it skips the first user frame.
if (!addedUserFrames
can be actual for LBR and hasBranchStack also but I can not proove.

I have committed version with one additional frame and regenerated log and diff with current KDAB version where you can see that all of added addresses have non-zero costs.
Sorry, I have no better explanation.
hotspot_generate_script_output.txt
hypot_finite.diff.txt

milianw · 2021-03-18T20:04:21Z

ok cool, this new version looks much simpler and together with the test I'm fine with merging it.

but when you write:

Probably we should not expect from lbr branchStack more exact address inside that callee but we still need it for Disassembly costs. It is the reason why I wanted to accumulate them into separate frames list.

If you think that based on the LBR it should be possible to distribute the sample cost across multiple adresses (versus just the call chain), then we need a different approach. I.e. that would mean we would basically have to split the single sample into multiple ones and then distribute the cost across them. It should not be a separate frames list!

dknysh · 2021-03-19T11:31:36Z

Ok, thanks. Should I upstream the changes to Qt?

milianw · 2021-03-21T09:44:17Z

yes please, always upstream everything

dknysh · 2021-03-30T11:40:42Z

gerrit Change-Id: Ie6413415c573e659505a4715978c65fce135d979

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 mentioned this pull request Mar 2, 2021

LBR unwinding method processing enhancement for Disassembly KDAB/hotspot#281

Closed

milianw suggested changes Mar 14, 2021

View reviewed changes

dknysh force-pushed the features/nips branch 2 times, most recently from a9d8f16 to cf1845a Compare March 17, 2021 07:46

dknysh force-pushed the features/nips branch from cf1845a to a1fff8a Compare March 17, 2021 09:05

dknysh force-pushed the features/nips branch from a1fff8a to 3601ee9 Compare March 18, 2021 11:14

dknysh force-pushed the features/nips branch from 3601ee9 to 4422ae2 Compare March 18, 2021 11:18

milianw merged commit b708d63 into KDAB:hotspot Mar 18, 2021

lievenhey mentioned this pull request Oct 11, 2024

feat: fix crash in qt6 #35

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

LBR unwinding method processing enhancement for Disassembly.#18

LBR unwinding method processing enhancement for Disassembly.#18
milianw merged 1 commit intoKDAB:hotspotfrom
dknysh:features/nips

dknysh commented Mar 2, 2021

Uh oh!

milianw left a comment

Uh oh!

milianw Mar 14, 2021

Uh oh!

dknysh commented Mar 17, 2021 •

edited

Loading

Uh oh!

milianw commented Mar 17, 2021

Uh oh!

dknysh commented Mar 17, 2021 •

edited

Loading

Uh oh!

milianw commented Mar 17, 2021

Uh oh!

dknysh commented Mar 18, 2021 •

edited

Loading

Uh oh!

milianw commented Mar 18, 2021

Uh oh!

dknysh commented Mar 19, 2021

Uh oh!

milianw commented Mar 21, 2021

Uh oh!

dknysh commented Mar 30, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

dknysh commented Mar 2, 2021

Uh oh!

milianw left a comment

Choose a reason for hiding this comment

Uh oh!

milianw Mar 14, 2021

Choose a reason for hiding this comment

Uh oh!

dknysh commented Mar 17, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

milianw commented Mar 17, 2021

Uh oh!

dknysh commented Mar 17, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

milianw commented Mar 17, 2021

Uh oh!

dknysh commented Mar 18, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

milianw commented Mar 18, 2021

Uh oh!

dknysh commented Mar 19, 2021

Uh oh!

milianw commented Mar 21, 2021

Uh oh!

dknysh commented Mar 30, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

dknysh commented Mar 17, 2021 •

edited

Loading

dknysh commented Mar 17, 2021 •

edited

Loading

dknysh commented Mar 18, 2021 •

edited

Loading