64bit linux -- can't play anything

[rokclimb15]

It might work, but there's no reason why you can't build with -g. From your sigsegv, it looks like a null pointer got freed. Try installing libudev-dbg (if available) and running again. It might give more detail.

This looks related:

https://bugs.freedesktop.org/show_bug.cgi?format=multiple&id=71543

edit: reading through that bug, it seems like you've built your own libsdl2 from source and it may have conflicts with the installed udev. Notice that you've got a libudev.so.0 and libudev.so.1. When building libsdl2, you probably need to use -Bsymbolic to avoid conflicts between those two libs. Or perhaps remove the system libudev (although that's likely to break things). Another option is to build libsdl2 and configure it to reference the installed libudev instead of building (what I assume) is a bundled copy.

It's the same set of symptoms, but a different root cause. You don't have Steam in this case, but your newer Mesa build causes the system libudev to get loaded first, then SDL brings its own copy to the party and things get confusing.

[hwangste]

Is this problem similar to the one we were discussing on the thread in the support forum ( https://forums.dolphin-emu.org/Thread-dolphin-4-0-on-ubuntu-12-04 )? We also reported that Dolphin would crash upon trying to load any game (right after giving the double buffered visual message). I haven't replied to that thread in a while becuase I borked my system messing with libglx.so and I haven't had a chance since fixing that mess to explore any more.

I've now given it another try with the latest source but the same problem remains. Following Shonumi's instructions, I compiled with -g and ran dolphin using gdb. This is the output I got right before the crash:

20:36:490 /home/hwangste/dolphin-emu/Source/Core/DolphinWX/Src/GLInterface/GLX.cpp:88 N[Video]: glX-Version 1.4
20:36:491 /home/hwangste/dolphin-emu/Source/Core/DolphinWX/Src/GLInterface/GLX.cpp:110 N[Video]: Got double buffered visual!
[New Thread 0x7fffb0ffb700 (LWP 16305)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd6096700 (LWP 16275)]
0x00007fffe80e6005 in udev_list_entry_get_name () from /lib/x86_64-linux-gnu/libudev.so.1
(gdb) quit
A debugging session is active.

Inferior 1 [process 16250] will be killed.

Any thoughts on what the next step should be?

[rokclimb15]

Looks the same to me. Can you include the full traceback from gdb? (type in bt at prompt)

I'd like to see if your conflict is coming from a homebrew copy of libsdl2 or if it's coming from Steam or some other source.

[hwangste]

Here's the traceback output from gdb:

#0 0x00007fffe80e6005 in udev_list_entry_get_name () from /lib/x86_64-linux-gnu/libudev.so.1
#1 0x00007fffe80eac6c in udev_monitor_filter_update () from /lib/x86_64-linux-gnu/libudev.so.1
#2 0x00007fffb01f58a1 in udev_monitor_enable_receiving () from /lib/x86_64-linux-gnu/libudev.so.0
#3 0x00007ffff3fc9a18 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#4 0x00007ffff3f613cc in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#5 0x00007ffff3f36135 in SDL_InitSubSystem () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#6 0x00000000006a314c in ciface::SDL::Init (devices=...)
at /home/hwangste/dolphin-emu/Source/Core/InputCommon/Src/ControllerInterface/SDL/SDL.cpp:33
#7 0x000000000069a71d in ControllerInterface::Initialize (this=0x15fdd80 <g_controller_interface>)
at /home/hwangste/dolphin-emu/Source/Core/InputCommon/Src/ControllerInterface/ControllerInterface.cpp:62
#8 0x000000000058b361 in Pad::Initialize (hwnd=0x5400002)
at /home/hwangste/dolphin-emu/Source/Core/Core/Src/HW/GCPad.cpp:43
#9 0x000000000053f88c in Core::EmuThread () at /home/hwangste/dolphin-emu/Source/Core/Core/Src/Core.cpp:406
#10 0x00007ffff04afe40 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#11 0x00007ffff3d0ce0e in start_thread (arg=0x7fffdd62c700) at pthread_create.c:311
#12 0x00007fffefa1a0fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113


It looks like libsdl2 is involved. I'm pretty sure I didn't compile my own version, though. It was installed from the official Debian unstable repository (the libsdl2-2.0-0 package, to be specific).

[Shonumi]

Fwiw, I've never had an issue with SDL 2.0 on my system. I grabbed the source tarball from their main site and built it from source with no fancy options (configure, make, make install, nothing else). Could be an issue with certain versions of udev and SDL 2.0.

[rokclimb15]

Based on that output, I think this is just a udev bug, plain and simple. It is triggered by conflicting udev instances which seem to be caused by Mesa libGL. Something is supplying its own copy of libudev (probably Mesa) and the function names match up, but probably not the arguments or the type checking involved.

[hwangste]

Aha! I think I've solved it (at least for my install). Rokclimb15- your comment above about delibalta having both libudev.so.1 and libudev.so.0 got me thinking. I also had both of those and I poked around to see where they came from. libudev.so.0 came from the libudev0 package and libudev.so.1 came from the libudev1 package. On Debian unstable, at least, libudev0 no longer exists as a package for amd64. It does exist for several other unofficial architectures (see http://packages.debian.org/sid/libudev0 for details). At some point it must have been removed from amd64 and replaced with libudev1. However, the system doesn't get rid of libudev0 when libudev1 is installed (there isn't a conflicts or anything specified in the package; perhaps there isn't supposed to be one- I don't know what the usual procedure is for these situations). Anyhow, I removed the libudev0 package and all of a sudden dolphin loads games without crashing.

It wouldn't surprise me if many of the folks who have this problem and are using Debian (or a related distro) have both packages installed as well. On the two other Debian amd64 systems I have, one (an older one that hasn't been updated as regularly) only has libudev0. The other has both libudev0 and libudev1. If you are experiencing the problem of dolphin crashing when trying to load any game, I'd try purging the libudev0 package. Hope this helps someone else.

Do you guys think this is worth filing a bug against the libudev0 or libudev1 packages in Debian?

[rokclimb15]

Great detective work! The other user had Mint I think, which is downstream from Ubuntu, which is downstream from Debian. I'm guessing libGL or some other package depends on the "old" libudev and installs that 32-bit only package.

It seems to me that it only occurs if Mesa libGL (or some other intermediary) is loaded before libsdl. I'm not sure the packages actually conflict, rather the calling code that loads 0 needs to be upgraded. If you file the bug there the devs will definitely sort it out though. I'd link to that upstream bug for libsdl for reference.