Re: [Fceultra-discuss] Crash with recent nvidia drivers

[Lukas S. <lts...@gm...>]

> 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
>

 Hello Alexander,

Firstly, thank you for your detailed report of this issue.  I have heard
some vague reports of this issue, but have been unable to get a gdb
backtrace or strace so it has been difficult to diagnose.  I currently have
a nvidia 520 and a 220 (iirc) to test with and I have been unable to
reproduce the issue on Arch Linux 64bit.  I have not had a debian/ubuntu
installation on the machine with the nvidia hardware so I have not been
able to reproduce.  I installed ubuntu 10.04 in virtualbox (which uses some
other driver, not the nvidia driver which is what is relevant) and could
not reproduce the issue.  The nvidia drivers in Arch Linux are essentially
the stock unpatched drivers from nvidia -- is there any patching involved
in the nvidia drivers packaged in ubuntu/debian?

I have recently committed a minor change to the build system (r2538) that
affects the way scons compiles in libGL -- would you be able to test the
latest subversion version to see if you are still able to reproduce the
issue?

FYI our subversion server has changed URL due to a sourceforge stack
upgrade, so for the sake of clarity:

  svn checkout svn://svn.code.sf.net/p/fceultra/code/fceu fceultra-code

I'd really like to see FCEUX inclusion in Debian, and we are also nearing a
2.1.6 release.  If I get a chance, I will install wheezy onto my box with
the nvidia cards and see if I can reproduce the issue.

TLDR: Are the nvidia drivers in debian patched in any way? I can't
reproduce on Arch Linux 64 (I've been testing fceux with the latest xorg
stack throughout with latest nvidia etc with no issues with opengl). I'd
like to see any issues on Debian resolved and if I can reproduce the issue
on my own hardware I can at least start to diagnose the issue.  Also, could
you test r2538 please?

Thank you for your proactive feedback!  I'd really like to get these issues
ironed out.

Best Regards,
Lukas Sabota
sf: punkrockguy318 (prg318)