|
From: Alexander T. <ale...@gm...> - 2012-06-23 19:42:07
|
Hello all, I've been working on packaging FCEUX for Debian. Unfortunately, I've been slowed by a heisenbug. I often get a segmentation fault shortly after loading, less than a minute after starting, when running it outside of gdb, valgrind and strace. With any of these utilities, FCEUX doesn't crash anymore. Also, this was more pronounced on my amd64 desktop than my i386 laptop; the crash occurred always and very quickly after starting FCEUX on the former, while on the latter it might take half a minute for it to crash, or sometimes it would not crash at all. Using ulimit -c unlimited I could produce a core dump that gdb was then able to parse. On my amd64 desktop, the only usable stack frame appears to be at the first instruction (push %ebp, %ebp) of g_thread_proxy in glib, which makes this a not very trustworthy backtrace. On my i386 laptop, there is no usable stack frame at all. I noted that FCEUX ran fine within a chroot, as long as the system's /proc wasn't bound inside the chroot. I noted, by using strace, that the libraries that FCEUX invoked used a few files under /proc. What I wanted was some indication of what libraries were using stuff under /proc, and strace+ helped me do just that, by providing backtraces for every system call. One of the offenders was the nvidia closed source driver's libGL.so. I took a wild guess that this was it, uninstalled it, ran the vesa driver for a short while, and verified that yes, indeed, FCEUX ran perfectly with the vesa driver. Note that you really need to uninstall the glx component of nvidia's closed source driver; their libGL.so will be loaded anyway even if you're using another xorg driver, like vesa or nouveau. I also verified that I could make FCEUX not crash by having the nvidia driver installed, starting Xorg, uninstalling the nvidia glx component so that it won't be used, and then starting FCEUX. This crash has occurred for me with driver versions 295.53, 302.07 and 302.17, and will likely occur for all versions in between. I'm running Debian testing and their packaged version of the nvidia driver; I haven't tried nvidia's official installer yet to verify that that also has the same problem. I will do some more research, and then I might submit this as a bug to nvidia. No other GTK or SDL applications (as far as I've tested) manage to trigger this bug. TL;DR: Recent nvidia drivers cause FCEUX to crash shortly after start. Does this occur to anybody else? Anybody have any input? Regards, Alexander |