Advice obtaining backtrace for Okular crash

cfr · 2024-05-09 04:12:06

Note that I know nothing about debugging beyond the information provided by KDE and the Arch wiki explaining how to obtain a backtrace with debugging symbols. This is probably going to be fairly obvious.

I was trying to report a crash in Okular associated with a particular PDF document. (`microtype`'s user manual, in case it matters).

Downloading the debugging symbols involved a lot of connections, not all of which succeeded (some were 'reset by peer'). Despite this and despite the fact that the only files under `~/.cache/debuginfod/` are those just downloaded (with today's timestamp), I have 1.3G worth of symbols cached.

Okular ran fine and crashed fine. I initiated logging and things went insane. Finally, the OOM killer put gdb out of its misery and Konsole disappeared with it (for reasons I'm unclear about). Apparently, this means *nothing* actually gets written to disk?

The wiki suggests building the application without LTO and this is backed by https://bbs.archlinux.org/viewtopic.php?id=284629. That post links to https://sourceware.org/bugzilla/show_bu … =23710#c24 but it isn't clear what, if anything, came of that discussion.

I can probably figure out how to build Okular without LTO, but I'd like to know

if that is likely to be sufficient,
if it is likely to produce something useful to upstream and
if it can be done in isolation.

That is, if I'd have to build all of KDE without LTO to improve things, I'll probably just read Microtype's manual online or something until somebody with more computing resources gets bitten.

Or would it be possible to obtain something useful using a different debugger which is less prone to blowing up?

I have 8G of physical RAM and 8G of swap, so it really seems to me that it should be possible to run some debugger in a way which causes it to be less of a memory hog. I don't really understand how it managed to generate so much heat and take so much memory without writing anything whatsover to file.

I'm also worried that the information won't be useful anyway. I lost what was on screen because gdb crashed the emulator, but one of the last visible lines on screen (before it went insane) had several bits with something like 'optimised away' as if, even with the debugging symbols, crucial bits were missing from what it was looking for. However, I only know what that really means for Ti*k*Z and I doubt gdb is drawing pictures, so that's likely not a good model.

I can post the journal log if it would be helpful, but it's a perfectly standard-looking OOM cycle.

seth · 2024-05-09 06:43:56

What does the backtrace w/o debuginfod invocation look like?
Let alone that okular might just infinitely recurse (causing the crash) you can probably then https://wiki.archlinux.org/title/Debugi … l_download for the most relevant libraries instead of the entire KDE stack.

Lone_Wolf · 2024-05-09 11:23:23

you did install https://archlinux.org/packages/extra/x86_64/drkonqi/ and let that handle the crash report ?

cfr · 2024-05-09 19:16:20

Lone_Wolf wrote:

you did install https://archlinux.org/packages/extra/x86_64/drkonqi/ and let that handle the crash report ?

Yes, but (1) it doesn't always get triggered even when things crash, (2) it typically says the report is unlikely to be useful and (3) it isn't at all clear to me what happens to reports submitted this way - I've submitted at least two for Okular crashes recently, but they don't seem to show up if I search the lists of bug reports for Okular and (4) the reports don't include any debugging symbols (?).

But, yes, I generally do send them on the rare occasions drkonqi deems them potentially useful, I don't if I've recently sent one for the same kind of crash or if I'm too short of time. (For some reason, if you send a report, you can't also restart the application from drkonqi. I have no idea why that seemed a good design decision.)

cfr · 2024-05-09 19:17:26

seth wrote:

What does the backtrace w/o debuginfod invocation look like?
Let alone that okular might just infinitely recurse (causing the crash) you can probably then https://wiki.archlinux.org/title/Debugi … l_download for the most relevant libraries instead of the entire KDE stack.

I will keep the next one to post here. Or did you mean run gdb without debuginfod?

seth · 2024-05-09 19:19:08

run gdb without debuginfod

Just to gage where the bug is and what libs to manually select for debuginfod

Lone_Wolf · 2024-05-09 22:47:32

cfr wrote:

(2) it typically says the report is unlikely to be useful and (3) it isn't at all clear to me what happens to reports submitted this way

I had coredumps disabled , re-enabling them allowed drkonqi to get a useful report for a knetwalk crash..
When the report is useful there's an option to look at it instead of sending. It's called Developer information if I remember correctly .

Arch Linux

#1 2024-05-09 04:12:06

Advice obtaining backtrace for Okular crash

#2 2024-05-09 06:43:56

Re: Advice obtaining backtrace for Okular crash

#3 2024-05-09 11:23:23

Re: Advice obtaining backtrace for Okular crash

#4 2024-05-09 19:16:20

Re: Advice obtaining backtrace for Okular crash

#5 2024-05-09 19:17:26

Re: Advice obtaining backtrace for Okular crash

#6 2024-05-09 19:19:08

Re: Advice obtaining backtrace for Okular crash

#7 2024-05-09 22:47:32

Re: Advice obtaining backtrace for Okular crash

Board footer