https://bugs.kde.org/show_bug.cgi?id=388611
--- Comment #13 from Henrik Fehlauer <rk...@lab12.net> --- Someone else already posted the patch for plasma-framework, not sure whether taking advantage of my analysis or not. That's what I get from helping others instead of cleaning up my own patches in time :( > I'll try to post a follow-along how I arrived at the Plasma fix Here we go: 1. Establish which binary we can attach gdb to: That required a bit of intuition, because the xorg-session.log does not provide the source a message is coming from (journald would be better in that regard, because it shows binary and PID, see https://bugs.kde.org/show_bug.cgi?id=388389#c0). Looking at the bugs, it became pretty obvious there where different sources the message came from (Dolphin and something Plasma related which could be triggered via RSIBreak or hovering over a custom panel entry). For the next steps, let's focus on plasmashell, because we see the errors appearing in the output when starting a standalone plasmashell (after killing the original). 2. Think about what we are looking for: Essentially we need to find the source of the error message first, to be able to trace back where it was triggered in a second step, so that place can be fixed in the end. In comment 4 I already linked the commit adding the error message to Qt, but searching for "Empty filename passed to function" in qtbase is another way to lead us to https://code.woboq.org/qt5/qtbase/src/corelib/io/qfilesystemengine_unix.cpp.html#110 (code.woboq.org is an excellent site for interactively browsing through Qt and KDE sources, BTW). Sadly, emptyFileEntryWarning_() is a very simple static function, meaning with the usual compiler optimizations enabled in a stock Qt build we cannot set a breakpoint on it. As a workaround, we can set a breakpoint on something inside this function (this took me quite a while to realize, haha), in this case QMessageLogger::warning. Note that now a breakpoint could be triggered more often, i.e. also when other functions issue a warning, which we would need to ignore then. 3. Get a backtrace with gdb: - $ killall plasmashell - $ gdb plasmashell - $ run (or "r") - ctrl-c to interrupt program flow - $ break QMessageLogger::warning (or "b") - $ continue (or "c") - Move mouse over custom icon in panel, breakpoint should be hit. - $ backtrace (or "bt") - Verify that the warning was indeed triggered by something also appearing in qfilesystemengine_unix.cpp and thus belonging to emptyFileEntryWarning(). - Repeat continue + backtrace until we are at the right place. - ctrl-d to stop the debugger Note that at this point there are still some pieces missing in the backtrace, so we go to the next step to fix this. 4. Prepare debug symbols: On openSUSE, packages are split into multiple RPMs. The oss repo has the binaries and -devel packages (needed to run something and to be able to #include headers when developing, respectively). The debug repo has -debuginfo packages, those are important if you submit a backtrace to Bugzilla for example, giving you more complete backtraces. The debug repo also provides -debugsource packages, those contain the complete source code of functions, so you could step through every single line in a debugger and see where you are. Note that those packages are for system provided binaries, if you execute code compiled by yourself you'd just have to make sure to compile in debug mode (you'd still need -debuginfo packages for libraries you use). (For completeness: There is also the source repo containing .src.rpms, which include a .tar.gz of the upstream source and a spec file to build all of the other types of RPMs I mentioned from this, but that's not relevant here. If you are interested, use rpm2cpio and cpio to extract those RPMs and see what they contain.) Here, we perform the following steps: - Note the filename in the backtrace for lines you want to know more about. - Install corresponding debuginfo package using one of the following methods (make sure to have the debug repo enabled): - rpm -qf /usr/lib64/libQt5Core.so.5 (to get the package name), zypper in /usr/lib64/libQt5Core.so.5 - ctrl-shift-f search in your konsole history for the file to find complaints about the missing debuginfo, zypper install -C "debuginfo(build-id)=474186faf16585c4703a404a4fdc1bac4c03ea00" Trigger the breakpoint again, now some of the "()" should be replaced by actual function names. Repeat for more packages as needed, e.g. plasma-framework-debuginfo. Next, we want line numbers, so we need -debugsource packages. On openSUSE, for larger projects a single source RPM can be split into multiple binary/debuginfo RPMs. With "rpm -qi libQt5Core5" we get the name of the source RPM (libqt5-qtbase), so the package name would be "libqt5-qtbase-debugsource". As we are interested in fixing the lines concering plasma, we issue "zypper in plasma-framework-debugsource". Now we see the line number in the backtrace (svg.cpp:254 in my case). 5. Start hacking: - $ git clone kde:plasma-framework - $ $EDITOR plasma-framework/src/plasma/svg.cpp:254 Hope this makes some sense to you, feel free to post any follow-up questions you might have. I'd encourage you to try those steps for yourself with Dolphin, so we can determine why you are still getting those errors. -- You are receiving this mail because: You are watching all bug changes.
