Arch Linux

> no debugging symbols are available: the gdb backtrace is all ?? entries

That means you didn't enable debug symbols download [1]. It's usually as simple as:

$ coredumpctl gdb (then answer y when it asks "Enable debuginfod for this session?")
(gdb) set logging enabled
(gdb) bt (or bt full)

Then post gdb.txt

I tried to repro in a fresh VM but I don't have any ROMs. But having said that, it does crash on exit anyway, but who knows if it's the same crash. Traces attached.

[1] https://wiki.archlinux.org/title/Debugging/Getting_traces

> That means you didn't enable debug symbols download

gdb was able to download symbols for just about everything else. It told me dolphin-emu's symbols aren't available. (For some reason, I can't recompile the package either to get a local version :/)

> I tried to repro in a fresh VM but I don't have any ROMs.

If you use "Tools → Perform System Update", you can get the System Menu files from Nintendo's servers.

> It told me dolphin-emu's symbols aren't available

You're right. The debug pkg simply doesn't exist on the server. I don't know why this is the case. Inside the .BUILDINFO I see:

options = debug

which means it should be there. Something must be wrong in the workflow somewhere. Hopefully our PM knows what's going on?

> If you use "Tools → Perform System Update"

Ah, thanks for the tip. I can now repro. But we need those debug symbols...

Just pushed the debug package, it's quite a large beast :)

Version 1:5.0.r19433.34527cadcc-2 is still broken. Instead of crashing when a render window opens, it's now freezing.

Experimenting with the PKGBUILD locally, building in a clean chroot with the `extra-x86_64-build` archbuild script resulted in a package that behaves identically to the package from the repos, i.e. segfaults on render window creation for 1:5.0.r19368.dadbeb4bae-1, and freezes for 1:5.0.r19433.34527cadcc-2.

However, building the PKGBUILD in a "classic" clean chroot as outlined here (https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot#Classic_way) resulted in a package that worked normally.

The broken package from the `extra-x86_64-build` script is 9.4MiB, and the working package from the traditional chroot is 21.7MiB. Extracting the package and examining the binaries directly, the broken binaries are a combined 30.3MiB, while the working ones are a combined 52.9MiB. All other files within the packages are the same size.

Is the `extra-x86_64-build` script stripping something vital out of the binaries in the runup to compression? Is that script used by the Arch build servers?

> Instead of crashing when a render window opens, it's now freezing

Not for me, it still crashes...just takes longer for systemd-coredump to process it.

> However, building the PKGBUILD in a "classic" clean chroot<...>

That makes no sense whatsoever. extra-x86_64-build is just a wrapper around the classic method. They should be identical (unless something funky is going on in your setup, or it's just buggy).

Anyway, here's the latest backtrace. (I gave up on trying to get more as my VM's just don't have enough mem.)

>That makes no sense whatsoever. extra-x86_64-build is just a wrapper around the classic method. They should be identical

Yeah, it's odd. It's possible it's something on my end, but the results are the same across multiple attempts: Build with extra-x86_64-build, package behaves like the repo package. Build with the "classic" method, package works just fine.

I doubt it'll be much help, but here's the build logs for both if anyone wants to give them a look

> Yeah, it's odd

Actually, it's a devtools bug. devtools went through a reorg for the git migration...and now the classic method gives you a different makepkg.conf than if using extra-x86_64-build. There was also this bug [1] now fixed in [extra-testing]. It might even all be the same issue. Will investigate...

Anyway, back on topic. It could be different *FLAGS causing the different working/broken builds (or debug, or LTO, or...)

[1] https://gitlab.archlinux.org/archlinux/devtools/-/issues/149

> Anyway, back on topic. It could be different *FLAGS causing the different working/broken builds (or debug, or LTO, or...)
Disabling LTO stops the coredump on exit for me.

> Build with the "classic" method, package works just fine.

Ok, to clarify my rambling above :) The classic method is currently not ideal. As hinted at in the wiki, you have to provide a custom pacman.conf and makepkg.conf in order to achieve the same outcome as extra-x86_64-build. And because of the aforementioned devtools bug, this currently doesn't work (unless you use devtools-1:1.0.2-1 from [extra-testing]).

> Disabling LTO stops the coredump on exit for me.

Thanks @loqs. Your results match those of @illogician (due to the devtools situation outlined above).

Leaving LTO enabled and switching to clang also stopped the coredump on exit for me. See attached diff. Toolchain issue or perhaps just made it harder to reproduce.

Does `-ffat-lto-objects` help with gcc?

> Does `-ffat-lto-objects` help with gcc?
No. tested both with and without thin archive creation disabled in CMakeLists.txt. Are you unable to reproduce the issue locally?

Dupe  FS#78819 

Please review above dupe because it contains an interesting workaround i.e. build with gcc-12

More dupes  FS#78926   FS#78985 

Still nothing, fails to load video backend.

version 5.0-19870

the dolphin-emu-git version from aur seems to work all of a sudden, not sure what is going on.

@Jumpingmanjim with LTO enabled or disabled?

I just downloaded it with yay. How can I check if LTO is enabled or not?

dolphin-emu-git disables LTO [1] so unless you overrode that it is built with LTO disabled which would explain why it does not have the issue.

[1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=dolphin-emu-git&id=3a143a0c48aa0732ed71b46a67afb4ba63447e6d#n27

how important is lto for performance anyway?

I fixed this, I believe. It was -O2. Please check rel-2.

dolphin-emu-1:5.0.r19870.032c77b462-2 for me still produces Segmentation fault (core dumped)
Reinstating O2 and disabling LTO and I can no longer reproduce the issue.

That's odd, it definitely fixes a crash for me. Will check lto.

I confirmed disabling lto also fixes it. This is probably preferable.