All of a sudden "Segmentation Fault"

[Bladeforce]

Hi, I run my games using the command line in Ubuntu and getting the following error when running:

ade@ade-G41D3C:~/.local/share/applications$ fs-uae "/home/ade/Documents/FS-UAE/Configurations/Walker.fs-uae"
Segmentation fault
ade@ade-G41D3C:~/.local/share/applications$ fs-uae "/home/ade/Documents/FS-UAE/Configurations/Cannon Fodder.fs-uae"
Segmentation fault

Now i recently tried out the beta nvidia driver 340 series so i am presuming this is the problem so i will go back to the 337 series and see if the fault has gone...just reporting fs-uae is the only emulator i have problems with as regards this 340 beta driver

Edit..

I can confirm on my machine the beta 340 nvidia driver does indeed cause a segmentation fault on my machine when running fs-uae. I went back to the 337 driver and all is fine. With the 340 driver on fs-uae seemed to have this problem none of my other emulators had this problem

[toxicshadow]

Glad you posted this. It suddenly stopped working for me and I could not think what would have caused it.

Good catch on the beta driver. Hopefully the issue can easily be resolved from either the developer side or by Nvidia themselves. Sadly I will have to live without fs-uae for a little while as the previous drivers cause a weird flicker bug when using some simple apps such as gedit

[FrodeSolheim]

Well, the bug could be either here or there Perhaps it is slightly more likely a driver bug since it works on older drivers, and also on drivers from other vendors and on other platforms.

I probably will not be able test with the nvidia driver myself for a couple of weeks. Perhaps you can try to run fs-uae through gdb. Tip: include --no-automatic-input-grab when running, so your pointer won't be locked when gdb freezes the process. e.g gdb --args fs-uae --no-automatic-input-grab.

[toxicshadow]

Sorry for taking so long to respond. Attached is the response from GDB:

(gdb) start
Function "main" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n

Starting program: /usr/bin/fs-uae --no-automatic-input-grab
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
__memmove_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1698
1698 ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S: No such file or directory.

Hello!

I've also started experiencing this on Arch Linux, again with the Nvidia 340 driver. I've tried FS-UAE versions 2.4.1 and 2.5.5dev (both built from the Arch AUR) and I get the segfault with both.


(gdb) start
Function "main" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
Starting program: /usr/bin/fs-uae
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0xf7731d35 in __memcpy_ssse3_rep () from /usr/lib32/libc.so.6
(gdb) backtrace
#0 0xf7731d35 in __memcpy_ssse3_rep () from /usr/lib32/libc.so.6
#1 0xf7c816ef in ?? () from /usr/lib32/libGL.so.1
#2 0xf6850496 in ?? () from /usr/lib32/libnvidia-glcore.so.340.24
#3 0xf7c618df in ?? () from /usr/lib32/libGL.so.1
#4 0xf7fe8aee in call_init.part () from /lib/ld-linux.so.2
#5 0xf7fe8c40 in _dl_init_internal () from /lib/ld-linux.so.2
#6 0xf7fdabaf in _dl_start_user () from /lib/ld-linux.so.2

[FrodeSolheim]

@hodge thanks for the stack trace -It shows that the crash happens inside the OpenGL driver. I cannot 100% say that there is no problem with FS-UAE, but FS-UAE works with other OpenGL drivers (incl. nVIDIA) on multiple platforms.

Thanks for the response! I'll check things out at nVidia's end and file a bug report if appropriate.

[alkis]

Got exactly the same problem (kubuntu 14.04-64bit with 340.24 nvidia driver)

__memmove_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1698
1698 ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S: No such file or directory.
(gdb) bt
#0 __memmove_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1698
#1 0x00007ffff3347d77 in ?? () from /usr/lib/nvidia-340/libnvidia-glcore.so.340.24
#2 0x00007ffff3347e58 in ?? () from /usr/lib/nvidia-340/libnvidia-glcore.so.340.24
#3 0x00007ffff6e9d6bd in ?? () from /usr/lib/nvidia-340/libGL.so.1
#4 0x00007ffff7dea0fd in call_init (l=0x7ffff7fc24f8, argc=argc@entry=1,
argv=argv@entry=0x7fffffffd158, env=env@entry=0x7fffffffd168) at dl-init.c:64
#5 0x00007ffff7dea223 in call_init (env=<optimized out>, argv=<optimized out>, argc=<optimized out>,
l=<optimized out>) at dl-init.c:36
#6 _dl_init (main_map=0x7ffff7ffe1c8, argc=1, argv=0x7fffffffd158, env=0x7fffffffd168)
at dl-init.c:126
#7 0x00007ffff7ddb30a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#8 0x0000000000000001 in ?? ()
#9 0x00007fffffffd59b in ?? ()
#10 0x0000000000000000 in ?? ()

[alkis]

Found a workarround.
This on terminal starts fs-uae correctly:
__GL_WRITE_TEXT_SECTION=0 fs-uae

And the relative documentation for it (/usr/share/doc/nvidia-340/html/openglenvvariables.html)
Disabling executable memory optimizations

By default, the NVIDIA driver will attempt to use optimizations which rely on being able to write to executable memory. This may cause problems in certain system configurations (e.g., on SELinux when the "allow_execmem" boolean is disabled or "deny_execmem" boolean is enabled, and on grsecurity kernels configured with CONFIG_PAX_MPROTECT). When possible, the driver will attempt to detect when it is running on an unsupported configuration and disable these optimizations automatically. If the __GL_WRITE_TEXT_SECTION environment variable is set to 0, the driver will unconditionally disable these optimizations.

I can confirm that the workaround allows fs-uae to start here as well, so thanks alkis .

(Oddly, I'm now experiencing a segfault when I *exit* fs-uae - though in practice that's not really a problem).

I started a thread over at the nVIDIA forums - no replies yet, but if more people make some noise we might get someone's attention .

http://tinyurl.com/fsuae-nvidia-segfault

[FrodeSolheim]

I have tested the latest nVidia drivers ( 340.32 ) on Linux and I can confirm that it does crash (same stack trace as alkis).

The problem is that the nVidia driver crashes as part of the nVidia OpenGL library initialization, *before* FS-UAE is even started...

I don't have any good explanation why it causes FS-UAE to crash and not all other OpenGL-using apps. One possibility is that the problem occurs only in specific circumstances (depending on library load order, size of executable, and/or something else).

Until the problem is resolved, one possible workaround I can do is to set __GL_WRITE_TEXT_SECTION=0 by Launcher/Arcade before starting FS-UAE (thanks for finding the workaround, alkis )

[alkis]

Originally Posted by FrodeSolheim

thanks for finding the workaround, alkis

You are quite welcome. Thank YOU for all the hard and amazing work, dude!

[FrodeSolheim]

The bug in FS-UAE causing the crash has been identified... by NVIDIA

FS-UAE bugfix release and more information at http://fs-uae.net/2015/01/27/fs-uae-2-4-3-released.

[Foul]

Is NVIDIA playing with Amiga ?

[Doc Mindie]

Originally Posted by FrodeSolheim

The bug in FS-UAE causing the crash has been identified... by NVIDIA

FS-UAE bugfix release and more information at http://fs-uae.net/2015/01/27/fs-uae-2-4-3-released.

Colour me impressed by nVidia... I wonder if Apple or Microsoft could've been bovvered to do the same if the bug was related OSX or Redmond instead of a driver.

Great that nVidia took their time to investigate