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

[Alexander T. <ale...@gm...>]

Hello Lukas,

I've managed to devise what may be a workaround for the problem. I
noticed that the original source distribution worked correctly, while
my packaged version crashed. I narrowed it down to that I added
-Wl,--as-needed to the link flags (env.Append(LINKFLAGS=
['-Wl,--as-needed'])). The reason I add this is that otherwise, the
fceux binary will link with libraries which it doesn't use directly
(but which are used indirectly), like libfontconfig, and that would
require a direct dependency between the fceux package and those
packages.
libGL was one of those libraries that were linked with, but from which
no symbols were imported from. I found this strange, took a look at
sdl-opengl.cpp and noticed that all GL symbols were imported at
run-time. There's no need to import GL symbols at run-time, except for
symbols from extensions, and you usually link against the core GL
symbols at compile-time.
So I modified the code to do that, and magically, the crashes I've
been having disappeared. At the same time, I could remove a lot of
lines from the file in question, which is never bad ;)
I've attached the patch to do this.

// Alexander

On Sun, Jun 24, 2012 at 3:36 AM, Lukas Sabota <lts...@gm...> wrote:
>
>>
>> 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)
>