Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

No way to copy the backtrace out of the messagehandler dialog #25

Closed
krf opened this issue Nov 19, 2012 · 2 comments
Closed

No way to copy the backtrace out of the messagehandler dialog #25

krf opened this issue Nov 19, 2012 · 2 comments
Assignees
@milianw
Labels
enhancement junior job
Milestone
2.2

Comments

@krf
Copy link
Contributor

krf commented Nov 19, 2012

Example: http://wstaw.org/m/2012/11/19/plasma-desktopCf1097.png

There's no way to copy the backtrace from that dialog.

A good solution would be to add a "Copy backtrace" button in the dialog which copies it to the clipboard. (Just like DrKonqi does it).
@ghost ghost assigned milianw Nov 30, 2012
@winterz
Copy link
Member

winterz commented Jan 18, 2013

I moved this into the 1.3 milestone. Milian or Kevin, would you have time to implement this within the next few days?

@AndriyP AndriyP mentioned this issue Sep 27, 2013
Open
@krf krf removed this from the 2.0 milestone Apr 17, 2014
@davidedmundson davidedmundson mentioned this issue Jul 2, 2014
Closed
@vkrause vkrause modified the milestone: 2.0.2 Jul 17, 2014
@winterz winterz added this to the 2.2 milestone Aug 30, 2014
@tmcguire tmcguire mentioned this issue Dec 17, 2014
Closed
@aleixpol aleixpol mentioned this issue Jan 15, 2015
Closed
@agabor agabor mentioned this issue Feb 7, 2015
Merged
@krf
Copy link
Contributor Author

krf commented Feb 10, 2015

Fixed by: #110

@krf krf closed this as completed Feb 10, 2015
@milianw milianw mentioned this issue Apr 30, 2015
Closed
@allopislozano allopislozano mentioned this issue Oct 31, 2017
Closed
@hallarempt hallarempt mentioned this issue Sep 17, 2018
Closed
milianw added a commit to milianw/GammaRay that referenced this issue May 6, 2020
@milianw
Don't crash when attaching to QiTissue
838658a 
This patch fixes runtime attaching to an ASAN-enabled QiTissue.
Previously I got the following crash reliably at startup:

```
==352112==ERROR: AddressSanitizer: SEGV on unknown address 0x604016000459 (pc 0x7feb421bed63 bp 0x7ffdaed25490 sp 0x7ffdaed25478 T0)
==352112==The signal is caused by a READ memory access.
    #0 0x7feb421bed62 in QHashData::nextNode(QHashData::Node*) (/usr/lib/libQt5Core.so.5+0x104d62)
    KDAB#1 0x7fea9efc9932 in QHash<GammaRay::ToolFactory*, QHashDummyValue>::iterator::operator++() /usr/include/qt/QtCore/qhash.h:345
    KDAB#2 0x7fea9efc8663 in QSet<GammaRay::ToolFactory*>::iterator::operator++() /usr/include/qt/QtCore/qset.h:129
    KDAB#3 0x7fea9efc6e0c in GammaRay::ToolManager::objectAdded(QMetaObject const*) ../core/toolmanager.cpp:217
    KDAB#4 0x7fea9efc6b67 in GammaRay::ToolManager::objectAdded(QObject*) ../core/toolmanager.cpp:194
    KDAB#5 0x7fea9efa7b22 in GammaRay::Probe::objectFullyConstructed(QObject*) ../core/probe.cpp:688
    KDAB#6 0x7fea9efa76b0 in GammaRay::Probe::objectAdded(QObject*, bool) ../core/probe.cpp:612
    KDAB#7 0x7fea9efa8a30 in GammaRay::Probe::discoverObject(QObject*) ../core/probe.cpp:907
    KDAB#8 0x7fea9efa8876 in GammaRay::Probe::findExistingObjects() ../core/probe.cpp:889
    KDAB#9 0x7fea9efa6097 in GammaRay::Probe::createProbe(bool) ../core/probe.cpp:351
    KDAB#10 0x7fead53fb5e7 in GammaRay::ProbeCreator::createProbe() ../probe/probecreator.cpp:92
    KDAB#11 0x7fead53fae5f in GammaRay::ProbeCreator::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) probe/gammaray_probe_obj_autogen/EWIEGA46WW/moc_probecreator.cpp:72
    KDAB#12 0x7feb4238cad9 in QObject::event(QEvent*) (/usr/lib/libQt5Core.so.5+0x2d2ad9)
    KDAB#13 0x7feb43294351 in QApplicationPrivate::notify_helper(QObject*, QEvent*) (/usr/lib/libQt5Widgets.so.5+0x15b351)
    KDAB#14 0x7feb4329d828 in QApplication::notify(QObject*, QEvent*) (/usr/lib/libQt5Widgets.so.5+0x164828)
    KDAB#15 0x7feb4235f4f1 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (/usr/lib/libQt5Core.so.5+0x2a54f1)
    KDAB#16 0x7feb42361d55 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (/usr/lib/libQt5Core.so.5+0x2a7d55)
    KDAB#17 0x7feb423b8243  (/usr/lib/libQt5Core.so.5+0x2fe243)
    KDAB#18 0x7feb206da6bd in g_main_context_dispatch (/usr/lib/libglib-2.0.so.0+0x6b6bd)
    KDAB#19 0x7feb206dc530  (/usr/lib/libglib-2.0.so.0+0x6d530)
    KDAB#20 0x7feb206dc570 in g_main_context_iteration (/usr/lib/libglib-2.0.so.0+0x6d570)
    KDAB#21 0x7feb423b788f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (/usr/lib/libQt5Core.so.5+0x2fd88f)
    KDAB#22 0x7feb4235e05b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (/usr/lib/libQt5Core.so.5+0x2a405b)
    KDAB#23 0x7feb42366065 in QCoreApplication::exec() (/usr/lib/libQt5Core.so.5+0x2ac065)
    KDAB#24 0x5643dbe05406 in main ../KDAB/qitissue/main.cpp:258
    KDAB#25 0x7feb41269022 in __libc_start_main (/usr/lib/libc.so.6+0x27022)
    KDAB#26 0x5643dbdfd1ed in _start (/home/milian/projects/kdab/qitissue/build-asan/bin/QiTissue+0x6b1ed)
```

I can only explain this by assuming that the list got mutated while
iterating over it, i.e. basically a recursion of `objectAdded` which
could happen when we init the factory?
milianw added a commit that referenced this issue May 7, 2020
@milianw
Don't crash when attaching to QiTissue
d0658e1 
This patch fixes runtime attaching to an ASAN-enabled QiTissue.
Previously I got the following crash reliably at startup:

```
==352112==ERROR: AddressSanitizer: SEGV on unknown address 0x604016000459 (pc 0x7feb421bed63 bp 0x7ffdaed25490 sp 0x7ffdaed25478 T0)
==352112==The signal is caused by a READ memory access.
    #0 0x7feb421bed62 in QHashData::nextNode(QHashData::Node*) (/usr/lib/libQt5Core.so.5+0x104d62)
    #1 0x7fea9efc9932 in QHash<GammaRay::ToolFactory*, QHashDummyValue>::iterator::operator++() /usr/include/qt/QtCore/qhash.h:345
    #2 0x7fea9efc8663 in QSet<GammaRay::ToolFactory*>::iterator::operator++() /usr/include/qt/QtCore/qset.h:129
    #3 0x7fea9efc6e0c in GammaRay::ToolManager::objectAdded(QMetaObject const*) ../core/toolmanager.cpp:217
    #4 0x7fea9efc6b67 in GammaRay::ToolManager::objectAdded(QObject*) ../core/toolmanager.cpp:194
    #5 0x7fea9efa7b22 in GammaRay::Probe::objectFullyConstructed(QObject*) ../core/probe.cpp:688
    #6 0x7fea9efa76b0 in GammaRay::Probe::objectAdded(QObject*, bool) ../core/probe.cpp:612
    #7 0x7fea9efa8a30 in GammaRay::Probe::discoverObject(QObject*) ../core/probe.cpp:907
    #8 0x7fea9efa8876 in GammaRay::Probe::findExistingObjects() ../core/probe.cpp:889
    #9 0x7fea9efa6097 in GammaRay::Probe::createProbe(bool) ../core/probe.cpp:351
    #10 0x7fead53fb5e7 in GammaRay::ProbeCreator::createProbe() ../probe/probecreator.cpp:92
    #11 0x7fead53fae5f in GammaRay::ProbeCreator::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) probe/gammaray_probe_obj_autogen/EWIEGA46WW/moc_probecreator.cpp:72
    #12 0x7feb4238cad9 in QObject::event(QEvent*) (/usr/lib/libQt5Core.so.5+0x2d2ad9)
    #13 0x7feb43294351 in QApplicationPrivate::notify_helper(QObject*, QEvent*) (/usr/lib/libQt5Widgets.so.5+0x15b351)
    #14 0x7feb4329d828 in QApplication::notify(QObject*, QEvent*) (/usr/lib/libQt5Widgets.so.5+0x164828)
    #15 0x7feb4235f4f1 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (/usr/lib/libQt5Core.so.5+0x2a54f1)
    #16 0x7feb42361d55 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (/usr/lib/libQt5Core.so.5+0x2a7d55)
    #17 0x7feb423b8243  (/usr/lib/libQt5Core.so.5+0x2fe243)
    #18 0x7feb206da6bd in g_main_context_dispatch (/usr/lib/libglib-2.0.so.0+0x6b6bd)
    #19 0x7feb206dc530  (/usr/lib/libglib-2.0.so.0+0x6d530)
    #20 0x7feb206dc570 in g_main_context_iteration (/usr/lib/libglib-2.0.so.0+0x6d570)
    #21 0x7feb423b788f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (/usr/lib/libQt5Core.so.5+0x2fd88f)
    #22 0x7feb4235e05b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (/usr/lib/libQt5Core.so.5+0x2a405b)
    #23 0x7feb42366065 in QCoreApplication::exec() (/usr/lib/libQt5Core.so.5+0x2ac065)
    #24 0x5643dbe05406 in main ../KDAB/qitissue/main.cpp:258
    #25 0x7feb41269022 in __libc_start_main (/usr/lib/libc.so.6+0x27022)
    #26 0x5643dbdfd1ed in _start (/home/milian/projects/kdab/qitissue/build-asan/bin/QiTissue+0x6b1ed)
```

I can only explain this by assuming that the list got mutated while
iterating over it, i.e. basically a recursion of `objectAdded` which
could happen when we init the factory?
milianw added a commit that referenced this issue Sep 21, 2021
@milianw
Don't crash when attaching to QiTissue
c95a4f5 
This patch fixes runtime attaching to an ASAN-enabled QiTissue.
Previously I got the following crash reliably at startup:

```
==352112==ERROR: AddressSanitizer: SEGV on unknown address 0x604016000459 (pc 0x7feb421bed63 bp 0x7ffdaed25490 sp 0x7ffdaed25478 T0)
==352112==The signal is caused by a READ memory access.
    #0 0x7feb421bed62 in QHashData::nextNode(QHashData::Node*) (/usr/lib/libQt5Core.so.5+0x104d62)
    #1 0x7fea9efc9932 in QHash<GammaRay::ToolFactory*, QHashDummyValue>::iterator::operator++() /usr/include/qt/QtCore/qhash.h:345
    #2 0x7fea9efc8663 in QSet<GammaRay::ToolFactory*>::iterator::operator++() /usr/include/qt/QtCore/qset.h:129
    #3 0x7fea9efc6e0c in GammaRay::ToolManager::objectAdded(QMetaObject const*) ../core/toolmanager.cpp:217
    #4 0x7fea9efc6b67 in GammaRay::ToolManager::objectAdded(QObject*) ../core/toolmanager.cpp:194
    #5 0x7fea9efa7b22 in GammaRay::Probe::objectFullyConstructed(QObject*) ../core/probe.cpp:688
    #6 0x7fea9efa76b0 in GammaRay::Probe::objectAdded(QObject*, bool) ../core/probe.cpp:612
    #7 0x7fea9efa8a30 in GammaRay::Probe::discoverObject(QObject*) ../core/probe.cpp:907
    #8 0x7fea9efa8876 in GammaRay::Probe::findExistingObjects() ../core/probe.cpp:889
    #9 0x7fea9efa6097 in GammaRay::Probe::createProbe(bool) ../core/probe.cpp:351
    #10 0x7fead53fb5e7 in GammaRay::ProbeCreator::createProbe() ../probe/probecreator.cpp:92
    #11 0x7fead53fae5f in GammaRay::ProbeCreator::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) probe/gammaray_probe_obj_autogen/EWIEGA46WW/moc_probecreator.cpp:72
    #12 0x7feb4238cad9 in QObject::event(QEvent*) (/usr/lib/libQt5Core.so.5+0x2d2ad9)
    #13 0x7feb43294351 in QApplicationPrivate::notify_helper(QObject*, QEvent*) (/usr/lib/libQt5Widgets.so.5+0x15b351)
    #14 0x7feb4329d828 in QApplication::notify(QObject*, QEvent*) (/usr/lib/libQt5Widgets.so.5+0x164828)
    #15 0x7feb4235f4f1 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (/usr/lib/libQt5Core.so.5+0x2a54f1)
    #16 0x7feb42361d55 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (/usr/lib/libQt5Core.so.5+0x2a7d55)
    #17 0x7feb423b8243  (/usr/lib/libQt5Core.so.5+0x2fe243)
    #18 0x7feb206da6bd in g_main_context_dispatch (/usr/lib/libglib-2.0.so.0+0x6b6bd)
    #19 0x7feb206dc530  (/usr/lib/libglib-2.0.so.0+0x6d530)
    #20 0x7feb206dc570 in g_main_context_iteration (/usr/lib/libglib-2.0.so.0+0x6d570)
    #21 0x7feb423b788f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (/usr/lib/libQt5Core.so.5+0x2fd88f)
    #22 0x7feb4235e05b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (/usr/lib/libQt5Core.so.5+0x2a405b)
    #23 0x7feb42366065 in QCoreApplication::exec() (/usr/lib/libQt5Core.so.5+0x2ac065)
    #24 0x5643dbe05406 in main ../KDAB/qitissue/main.cpp:258
    #25 0x7feb41269022 in __libc_start_main (/usr/lib/libc.so.6+0x27022)
    #26 0x5643dbdfd1ed in _start (/home/milian/projects/kdab/qitissue/build-asan/bin/QiTissue+0x6b1ed)
```

I can only explain this by assuming that the list got mutated while
iterating over it, i.e. basically a recursion of `objectAdded` which
could happen when we init the factory?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@milianw milianw

Labels
enhancement junior job
Projects
None yet
Milestone
2.2
Development

No branches or pull requests
4 participants
@krf @milianw @winterz @vkrause