callgrind mit Qt-GUI



  • Hallo,
    ich versuche bereits seit zwei Tagen, callgrind unter Linux zu verwenden, um ein Programm mit einer Qt-GUI zu profilen.
    Leider bekomme ich (unabhängig vom verwendeten Qt-Programm) dabei nur folgenden Output:

    ==10137== Callgrind, a call-graph generating cache profiler
    ==10137== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et al.
    ==10137== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info
    ==10137== Command: /path/to/program
    ==10137== 
    --10137-- warning: L3 cache found, using its data for the LL simulation.
    ==10137== For interactive control, run 'callgrind_control -h'.
    
    valgrind: m_debuginfo/debuginfo.c:453 (discard_or_archive_DebugInfo): Assertion 'is_DebugInfo_active(di)' failed.
    
    host stacktrace:
    ==10137==    at 0x58022AB4: show_sched_status_wrk (m_libcassert.c:369)
    ==10137==    by 0x58022BC7: report_and_quit (m_libcassert.c:440)
    ==10137==    by 0x58022D59: vgPlain_assert_fail (m_libcassert.c:506)
    ==10137==    by 0x58048DAC: discard_or_archive_DebugInfo (debuginfo.c:453)
    ==10137==    by 0x580497F6: vgPlain_di_notify_mmap (debuginfo.c:598)
    ==10137==    by 0x5807A74B: vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2402)
    ==10137==    by 0x580861EF: vgSysWrap_amd64_linux_sys_mmap_before (syswrap-amd64-linux.c:404)
    ==10137==    by 0x58075E61: vgPlain_client_syscall (syswrap-main.c:1863)
    ==10137==    by 0x580729FA: handle_syscall (scheduler.c:1176)
    ==10137==    by 0x580742B6: vgPlain_scheduler (scheduler.c:1498)
    ==10137==    by 0x580D5110: run_a_thread_NORETURN (syswrap-linux.c:103)
    
    sched status:
      running_tid=1
    
    Thread 1: status = VgTs_Runnable syscall 9 (lwpid 10137)
    ==10137==    at 0x401C277: mmap (in /usr/lib/ld-2.28.so)
    ==10137==    by 0x4007668: _dl_map_object_from_fd (in /usr/lib/ld-2.28.so)
    ==10137==    by 0x4009D6B: _dl_map_object (in /usr/lib/ld-2.28.so)
    ==10137==    by 0x401423E: dl_open_worker (in /usr/lib/ld-2.28.so)
    ==10137==    by 0x5E43E76: _dl_catch_exception (in /usr/lib/libc-2.28.so)
    ==10137==    by 0x4013DFE: _dl_open (in /usr/lib/ld-2.28.so)
    ==10137==    by 0x678F159: ??? (in /usr/lib/libdl-2.28.so)
    ==10137==    by 0x5E43E76: _dl_catch_exception (in /usr/lib/libc-2.28.so)
    ==10137==    by 0x5E43F12: _dl_catch_error (in /usr/lib/libc-2.28.so)
    ==10137==    by 0x678F8BE: ??? (in /usr/lib/libdl-2.28.so)
    ==10137==    by 0x678F1F9: dlopen (in /usr/lib/libdl-2.28.so)
    ==10137==    by 0x569456D: ??? (in /usr/lib/libQt5Core.so.5.11.2)
    ==10137==    by 0x568E1B5: ??? (in /usr/lib/libQt5Core.so.5.11.2)
    ==10137==    by 0x568E780: ??? (in /usr/lib/libQt5Core.so.5.11.2)
    ==10137==    by 0x5684660: QFactoryLoader::instance(int) const (in /usr/lib/libQt5Core.so.5.11.2)
    ==10137==    by 0x4F97D5E: QPlatformIntegrationFactory::create(QString const&, QStringList const&, int&, char**, QString const&) (in /usr/lib/libQt5Gui.so.5.11.2)
    ==10137==    by 0x4FA63E8: QGuiApplicationPrivate::createPlatformIntegration() (in /usr/lib/libQt5Gui.so.5.11.2)
    ==10137==    by 0x4FA742D: QGuiApplicationPrivate::createEventDispatcher() (in /usr/lib/libQt5Gui.so.5.11.2)
    ==10137==    by 0x569EA34: QCoreApplicationPrivate::init() (in /usr/lib/libQt5Core.so.5.11.2)
    ==10137==    by 0x4FA864F: QGuiApplicationPrivate::init() (in /usr/lib/libQt5Gui.so.5.11.2)
    ==10137==    by 0x498EB99: QApplicationPrivate::init() (in /usr/lib/libQt5Widgets.so.5.11.2)
    ==10137==    by 0x11C288: main (in /path/to/program)
    client stack range: [0x1FFEFFC000 0x1FFF000FFF] client SP: 0x1FFEFFE348
    valgrind stack range: [0x1002D9A000 0x1002E99FFF] top usage: 9144 of 1048576
    
    
    Note: see also the FAQ in the source distribution.
    It contains workarounds to several common problems.
    In particular, if Valgrind aborted or crashed after
    identifying problems in your program, there's a good chance
    that fixing those problems will prevent Valgrind aborting or
    crashing, especially if it happened in m_mallocfree.c.
    
    If that doesn't help, please report this bug to: www.valgrind.org
    
    In the bug report, send all the above text, the valgrind
    version, and what OS and version you are using.  Thanks.
    

    Die Ausgabedatei wird erstellt, bleibt aber leer.
    Aufgerufen wird callgrind via QtCreator mit

    valgrind --smc-check=stack --tool=callgrind --cache-sim=yes /path/to/program
    

    Der Aufruf direkt von der Konsole aus scheitert auf genau die gleiche Art und Weise.
    Ich bin mir allerdings relativ sicher, dass es früher auch schon einmal geklappt hatte (mehrere Monate her).
    Ausprobierte Versionen: 3.14 und 3.13.
    Hat jemand eine Idee, woran das liegen könnte und vllt. sogar eine Lösung?

    Danke!



  • Vlt eine blöde Frage, aber hast du dein Programm auch mit Debug Informationen kompiliert?



  • Ich vermute, dass du auf diese Zeile anspielst:

    valgrind: m_debuginfo/debuginfo.c:453 (discard_or_archive_DebugInfo): Assertion 'is_DebugInfo_active(di)' failed.
    

    Ich habe es mit Debug, Profile und Release im QtCreator ausprobiert, kommt immer diese Zeile. Bei Debug warnt mich der QtCreator allerdings auch, dass callgrind für optimierte Programme gedacht ist.



  • Debuginformationen und Optimizer schließen sich nicht aus.



  • @manni66 Ich ging aber ehrlich gesagt davon aus, dass im Profile-Mode genau dies gemacht wird. Dort funktioniert es aber ja auch nicht und es wird mir auch im Debug-Mode angezeigt. Als Non-GUI Anwendung (also ohne Qt) funktioniert es ja auch.



  • @unterfliege sagte in callgrind mit Qt-GUI:

    Ich ging aber ehrlich gesagt davon

    Davon geht man nicht aus. Man muss wissen was man da tut.



  • Stackoverflow behauptet ansonsten, dass der Aufruf so aussehen sollte:

    valgrind --tool=callgrind --trace-children=yes --demangle=yes ./MyProject```
    

    Außerdem sollten evt. die QT Libs auch Debuginformationen enthalten



  • @manni66 sagte in callgrind mit Qt-GUI:

    @unterfliege sagte in callgrind mit Qt-GUI:

    Ich ging aber ehrlich gesagt davon

    Davon geht man nicht aus. Man muss wissen was man da tut.

    Es gibt stets unterliegende Dinge, auf die du dich verlässt. Geht dir nicht anders. Und es ist nebenbei bemerkt genau so, wie ich sagte.

    Das Problem hat sich übrigens erledigt, war ein Bug.
    Der Fix war allerdings offensichtlich noch nicht im offiziellen Arch-Repo, vermutlich weil die Version immer noch die gleiche Nummer trägt (weiterhin 3.14.0). Selbst kompiliert und alles funktioniert wie es soll.


Anmelden zum Antworten