Retroarch: Segfault on rgui and ozone, NOT xmb

Created on 11 Sep 2020  ·  38Comments  ·  Source: libretro/RetroArch

Description

Retroarch crashes with segfault on ozone and rgui drivers when starting any core content if there exists at least 1 playlist.
I DO NOT have this problem with XMB driver.
This happens on Intel graphics chipset. No issues at all with Nvidia graphics!

Expected behavior

No crash

Actual behavior

Crash

Steps to reproduce the bug

Grab an Intel Graphics Notebook (like me it's Intel Graphics 3000 and 5500), create at least 1 playlist and run. It will segfault with any driver except XMB!

Bisect Results

Since first use

Version/Commit

v1.9.0

Environment information

  • OS: Arch Linux Kernel 5.8.7
  • Compiler: -

Most helpful comment

This all seems fine to me :)

  • No crashes with any gfx driver/menu driver combination

  • No crashes when toggling threaded video (when using nvidia gfx)

  • No crashes when automatically switching drivers on load content (via overrides)

  • No additional memory leaks

    • Pulse audio always leaks a few bytes anyway - that's not our fault

    • The Vulkan gfx driver is slightly leaky, but this is in the driver itself and happens on master as well (and always has)

    • The sdl2 gfx driver has quite a number of small leaks, but again this seems to happen in the sdl libraries and it's present on master as well

The crash when toggling threaded video on certain systems with intel gfx is unfortunate, but unrelated to this PR (and since it's a driver/mesa issue, there's not much we can do about it...)

@twinaphex Looks like #11323 is ready to go :)

All 38 comments

Can you give us a stacktrace?

This is all i get:

[INFO] [GL]: Found GL context: x
[INFO] [GL]: Detecting screen resolution 1920x1080.
[INFO] [GLX]: Window manager is Xfwm4.
[INFO] [XINERAMA]: Xinerama version: 1.1.
[INFO] [XINERAMA]: Xinerama screens: 1.
[INFO] [GLX]: Using Xinerama on screen #0.
[INFO] [GLX]: X = 0, Y = 0, W = 1920, H = 1080.
[INFO] [GLX]: Using windowed fullscreen.
[INFO] [GLX]: Found swap function: glXSwapIntervalEXT.
[INFO] [GLX]: glXSwapInterval(1)
[WARN] [GLX]: glXSwapInterval() failed.
[INFO] [GL]: Vendor: VMware, Inc., Renderer: llvmpipe (LLVM 10.0.1, 256 bits).
[INFO] [GL]: Version: 3.1 Mesa 20.1.7.
[INFO] [GL]: Using resolution 1920x1080
[INFO] [GL]: Default shader backend found: glsl.
[INFO] [Shader driver]: Using GLSL shader backend.
[INFO] [GLSL]: Checking GLSL shader support ...
[WARN] [GL]: Stock GLSL shaders will be used.
[INFO] [GLSL]: Found GLSL vertex shader.
[INFO] [GLSL]: Found GLSL fragment shader.
[INFO] [GLSL]: Linking GLSL program.
[INFO] [GLSL]: Found GLSL vertex shader.
[INFO] [GLSL]: Found GLSL fragment shader.
[INFO] [GLSL]: Linking GLSL program.
[INFO] [GLSL]: Found GLSL vertex shader.
[INFO] [GLSL]: Found GLSL fragment shader.
[INFO] [GLSL]: Linking GLSL program.
[INFO] [GL]: Using 4 textures.
[INFO] [GL]: Loaded 1 program(s).
[INFO] [GL]: Using GL_RGB565 for texture uploads.
[INFO] [udev]: Pad #0 (/dev/input/event19) supports force feedback.
[INFO] [udev]: Pad #0 (/dev/input/event19) supports 16 force feedback effects.
[INFO] [udev]: Pad #1 (/dev/input/event24) supports force feedback.
[INFO] [udev]: Pad #1 (/dev/input/event24) supports 16 force feedback effects.
[INFO] [Joypad]: Found joypad driver: "udev".
[INFO] [Font]: Using font rendering backend: freetype.
[INFO] [Video]: Found display server: x11
[New Thread 0x7fffb3807640 (LWP 1120751)]
[INFO] [PulseAudio]: Requested 24576 bytes buffer, got 18432.
[INFO] [Display]: Found display driver: "gl".

Thread 1 "retroarch" received signal SIGSEGV, Segmentation fault.

Can you recompile with debug symbols? This doesn't tell us much.

make clean
make DEBUG=1

OK, i have to dig into compiling. I will test a couple of other things and come back. Thanks.

Hm I'm not sure it's related since it even crashes with XMB for me, and I'm using Linux Mint, but I get this:

[INFO] [X11]: Suspending screensaver (X11, xdg-screensaver).
X Error of failed request:  BadName (named color or font does not exist)
  Major opcode of failed request:  141 (RANDR)
  Minor opcode of failed request:  16 (RRCreateMode)
  Serial number of failed request:  15
  Current serial number in output stream:  15

=================================================================
==48898==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 1971 byte(s) in 1 object(s) allocated from:
    #0 0x7ff554f44bc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7ff5536eb84d  (/usr/lib/x86_64-linux-gnu/libXrandr.so.2+0x684d)

Direct leak of 88 byte(s) in 1 object(s) allocated from:
    #0 0x7ff554f44bc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7ff55399078a in pa_xmalloc (/usr/lib/x86_64-linux-gnu/libpulse.so.0+0x3b78a)

SUMMARY: AddressSanitizer: 2059 byte(s) leaked in 2 allocation(s).

After bisecting, this is the first bad commit: 28463a9729890c51cf8fbcfce163d0b37d69dde8
I still get the 2nd LeakSanitizer thing (the one with libpulse I mean) with previous commits when I close RA, but no crash on content load.

Hi there @alphanu1, it's very concerning that apparently these crashes happen after the CRT PR.

I'm afraid I will have to revert this for now. Hopefully you can come up with a new PR that is less crash prone. Maybe doublecheck first if these crashes can happen and maybe coordinate things with some of the people mentioned in this issue?

@twinaphex I will have a look into this. I had no crashes loading cores on RGUI. This code only runs if CRTSwitchRes is activated. Are we sure this is the cause?

@bslenul @DocMAX Check now with the latest source if this issue no longer occurs.

@alphanu1 if it no longer occurs now on master then I think we have narrowed it down at least to the CRTSwitchRes PRs.

No crash with 49be963, I don't use the SwitchRes stuff, it's OFF for me.

I have located the issue. Once I raise the PR can @bslenul and @DocMAX test this please?

Sure thing! 👍

@bslenul @DocMAX Please can you test the new PR https://github.com/libretro/RetroArch/pull/11323.

Many Thanks.

Hm, compilation fails for me:

gfx/display_servers/dispserv_x11.c: In function ‘x11_display_server_set_resolution’:
gfx/display_servers/dispserv_x11.c:186:7: error: ‘crt_mode_flag’ undeclared (first use in this function)
  186 |       crt_mode_flag = 10;
      |       ^~~~~~~~~~~~~
gfx/display_servers/dispserv_x11.c:186:7: note: each undeclared identifier is reported only once for each function it appears in

@bslenul I just fixed that and merged.

No crash anymore for me on content load, however the memory leaks when closing RA are way worse than before:

=================================================================
==1563==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 176 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fbc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7fcf61f7b78a in pa_xmalloc (/usr/lib/x86_64-linux-gnu/libpulse.so.0+0x3b78a)

Indirect leak of 45696 byte(s) in 4 object(s) allocated from:
    #0 0x7fcf6352fdc6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
    #1 0x7fcf61d2c994 in XOpenDisplay (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x2e994)

Indirect leak of 42336 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fdc6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
    #1 0x7fcf5e97c884 in xcb_connect_to_fd (/usr/lib/x86_64-linux-gnu/libxcb.so.1+0xb884)

Indirect leak of 32768 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fdc6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
    #1 0x7fcf61d2c62f in XOpenDisplay (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x2e62f)

Indirect leak of 20008 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fffe in __interceptor_realloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe)
    #1 0x7fcf5e97ca62 in xcb_connect_to_fd (/usr/lib/x86_64-linux-gnu/libxcb.so.1+0xba62)

Indirect leak of 4688 byte(s) in 1 object(s) allocated from:
    #0 0x7fcf6352fdc6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
    #1 0x7fcf61d2c2e1 in XOpenDisplay (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x2e2e1)
    #2 0x55aee2fcc851 in video_display_server_destroy /home/bobby/Documents/RetroArch/retroarch.c:31135
    #3 0x55aee2ffbeac in retroarch_deinit_drivers /home/bobby/Documents/RetroArch/retroarch.c:35092
    #4 0x55aee2f31367 in main_exit /home/bobby/Documents/RetroArch/retroarch.c:17499
    #5 0x55aee2f32053 in rarch_main /home/bobby/Documents/RetroArch/retroarch.c:17627
    #6 0x55aee3459fef in main ui/drivers/qt/ui_qt_application.cpp:151
    #7 0x7fcf5f2ae0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

Indirect leak of 4688 byte(s) in 1 object(s) allocated from:
    #0 0x7fcf6352fdc6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
    #1 0x7fcf61d2c2e1 in XOpenDisplay (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x2e2e1)
    #2 0x55aee2fcc851 in video_display_server_destroy /home/bobby/Documents/RetroArch/retroarch.c:31135
    #3 0x55aee2fcc14a in video_display_server_init /home/bobby/Documents/RetroArch/retroarch.c:31081
    #4 0x55aee2fd6ad3 in video_driver_init_internal /home/bobby/Documents/RetroArch/retroarch.c:32044
    #5 0x55aee2ff9750 in drivers_init /home/bobby/Documents/RetroArch/retroarch.c:34849
    #6 0x55aee300eb62 in retroarch_main_init /home/bobby/Documents/RetroArch/retroarch.c:37171
    #7 0x55aee30541b8 in content_load tasks/task_content.c:607
    #8 0x55aee305af11 in command_event_cmd_exec tasks/task_content.c:1429
    #9 0x55aee305cd43 in task_push_load_content_from_playlist_from_menu tasks/task_content.c:1689
    #10 0x55aee3b4779f in default_action_ok_load_content_from_playlist_from_menu menu/cbs/menu_cbs_ok.c:1928
    #11 0x55aee3b4a3d0 in action_ok_playlist_entry_collection menu/cbs/menu_cbs_ok.c:2302
    #12 0x55aee2ebb74c in generic_menu_entry_action /home/bobby/Documents/RetroArch/retroarch.c:4776
    #13 0x55aee39db4e3 in ozone_menu_entry_action menu/drivers/ozone/ozone.c:525
    #14 0x55aee2ec0682 in menu_entry_action /home/bobby/Documents/RetroArch/retroarch.c:5210
    #15 0x55aee2eba5bc in generic_menu_iterate /home/bobby/Documents/RetroArch/retroarch.c:4701
    #16 0x55aee2ecf96b in menu_driver_iterate /home/bobby/Documents/RetroArch/retroarch.c:6813
    #17 0x55aee3023405 in runloop_check_state /home/bobby/Documents/RetroArch/retroarch.c:39273
    #18 0x55aee302a7e1 in runloop_iterate /home/bobby/Documents/RetroArch/retroarch.c:39857
    #19 0x55aee2f31e7b in rarch_main /home/bobby/Documents/RetroArch/retroarch.c:17610
    #20 0x55aee3459fef in main ui/drivers/qt/ui_qt_application.cpp:151
    #21 0x7fcf5f2ae0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

Indirect leak of 384 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fbc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7fcf61d29ed4  (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x2bed4)

Indirect leak of 336 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fdc6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
    #1 0x7fcf61d2cba7 in XOpenDisplay (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x2eba7)

Indirect leak of 320 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fbc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7fcf61d1a84f in XCreateGC (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x1c84f)

Indirect leak of 304 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fdc6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
    #1 0x7fcf61d92c8e in XkbUseExtension (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x94c8e)

Indirect leak of 256 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fdc6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
    #1 0x7fcf61d2c840 in XOpenDisplay (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x2e840)

Indirect leak of 256 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fdc6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
    #1 0x7fcf61d261ee in XInitExtension (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x281ee)

Indirect leak of 224 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fdc6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
    #1 0x7fcf61d2c910 in XOpenDisplay (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x2e910)

Indirect leak of 216 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fbc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7fcf61d2cdf1 in XOpenDisplay (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x2edf1)

Indirect leak of 208 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fdc6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
    #1 0x7fcf61d3ba02 in _XConnectXCB (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x3da02)

Indirect leak of 144 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fdc6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
    #1 0x7fcf61d2c691 in XOpenDisplay (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x2e691)

Indirect leak of 96 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fbc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7fcf61d3bb01 in _XConnectXCB (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x3db01)

Indirect leak of 96 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fbc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7fcf61d3bb17 in _XConnectXCB (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x3db17)

Indirect leak of 96 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fbc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7fcf61d29ef1  (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x2bef1)

Indirect leak of 96 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fbc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7fcf61d29f12  (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x2bf12)

Indirect leak of 80 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fbc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7fcf61d29f02  (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x2bf02)

Indirect leak of 80 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fbc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7fcf61d3dc21 in _XPollfdCacheInit (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x3fc21)

Indirect leak of 64 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fbc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7fcf5e97f0c5  (/usr/lib/x86_64-linux-gnu/libxcb.so.1+0xe0c5)

Indirect leak of 64 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fffe in __interceptor_realloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe)
    #1 0x7fcf5e97fb9e  (/usr/lib/x86_64-linux-gnu/libxcb.so.1+0xeb9e)

Indirect leak of 48 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fbc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7fcf61d3c105  (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x3e105)

Indirect leak of 42 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fbc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7fcf61d2c7ac in XOpenDisplay (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x2e7ac)

Indirect leak of 32 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fbc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7fcf61d29eba  (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x2beba)

Indirect leak of 32 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf6352fbc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7fcf5e97ff81  (/usr/lib/x86_64-linux-gnu/libxcb.so.1+0xef81)

Indirect leak of 20 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf634b83dd in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x963dd)
    #1 0x7fcf61d261fe in XInitExtension (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x281fe)

Indirect leak of 6 byte(s) in 2 object(s) allocated from:
    #0 0x7fcf634b83dd in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x963dd)
    #1 0x7fcf61d2c2f5 in XOpenDisplay (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x2e2f5)

SUMMARY: AddressSanitizer: 153860 byte(s) leaked in 62 allocation(s).

RA seems to close properly (it unloads core, saves config, etc.) so I have no idea if this is harmless or not.

Thanks @bslenul. I have added a free resource and close resource. Hopefully, that will clear up some of these leaks.

Would you mind checking this again?

Crashing again on content load:

AddressSanitizer:DEADLYSIGNAL
=================================================================
==21849==ERROR: AddressSanitizer: SEGV on unknown address 0x558cf8819876 (pc 0x7f941c927a06 bp 0x558cf8819876 sp 0x7ffd4270dd70 T0)
==21849==The signal is caused by a WRITE memory access.
    #0 0x7f941c927a05  (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x28a05)
    #1 0x7f941ca0c798 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10d798)
    #2 0x558cf882901e in x11_display_server_destroy gfx/display_servers/dispserv_x11.c:623
    #3 0x558cf7a97851 in video_display_server_destroy /home/bobby/Documents/RetroArch/retroarch.c:31135
    #4 0x558cf7a9714a in video_display_server_init /home/bobby/Documents/RetroArch/retroarch.c:31081
    #5 0x558cf7aa1ad3 in video_driver_init_internal /home/bobby/Documents/RetroArch/retroarch.c:32044
    #6 0x558cf7ac4750 in drivers_init /home/bobby/Documents/RetroArch/retroarch.c:34849
    #7 0x558cf7ad9b62 in retroarch_main_init /home/bobby/Documents/RetroArch/retroarch.c:37171
    #8 0x558cf7b1f1b8 in content_load tasks/task_content.c:607
    #9 0x558cf7b25f11 in command_event_cmd_exec tasks/task_content.c:1429
    #10 0x558cf7b27d43 in task_push_load_content_from_playlist_from_menu tasks/task_content.c:1689
    #11 0x558cf861279f in default_action_ok_load_content_from_playlist_from_menu menu/cbs/menu_cbs_ok.c:1928
    #12 0x558cf86153d0 in action_ok_playlist_entry_collection menu/cbs/menu_cbs_ok.c:2302
    #13 0x558cf798674c in generic_menu_entry_action /home/bobby/Documents/RetroArch/retroarch.c:4776
    #14 0x558cf84a64e3 in ozone_menu_entry_action menu/drivers/ozone/ozone.c:525
    #15 0x558cf798b682 in menu_entry_action /home/bobby/Documents/RetroArch/retroarch.c:5210
    #16 0x558cf79855bc in generic_menu_iterate /home/bobby/Documents/RetroArch/retroarch.c:4701
    #17 0x558cf799a96b in menu_driver_iterate /home/bobby/Documents/RetroArch/retroarch.c:6813
    #18 0x558cf7aee405 in runloop_check_state /home/bobby/Documents/RetroArch/retroarch.c:39273
    #19 0x558cf7af57e1 in runloop_iterate /home/bobby/Documents/RetroArch/retroarch.c:39857
    #20 0x558cf79fce7b in rarch_main /home/bobby/Documents/RetroArch/retroarch.c:17610
    #21 0x558cf7f24fef in main ui/drivers/qt/ui_qt_application.cpp:151
    #22 0x7f941878b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    #23 0x558cf796461d in _start (/home/bobby/Documents/RetroArch/retroarch+0x4b7861d)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x28a05) 
==21849==ABORTING

And if I close RA without loading anything:

==21941==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x7ffdae5582c0 in thread T0
    #0 0x7fb7379727cf in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10d7cf)
    #1 0x55afe3e3401e in x11_display_server_destroy gfx/display_servers/dispserv_x11.c:623
    #2 0x55afe30a2851 in video_display_server_destroy /home/bobby/Documents/RetroArch/retroarch.c:31135
    #3 0x55afe30d1eac in retroarch_deinit_drivers /home/bobby/Documents/RetroArch/retroarch.c:35092
    #4 0x55afe3007367 in main_exit /home/bobby/Documents/RetroArch/retroarch.c:17499
    #5 0x55afe3008053 in rarch_main /home/bobby/Documents/RetroArch/retroarch.c:17627
    #6 0x55afe352ffef in main ui/drivers/qt/ui_qt_application.cpp:151
    #7 0x7fb7336f10b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    #8 0x55afe2f6f61d in _start (/home/bobby/Documents/RetroArch/retroarch+0x4b7861d)

Address 0x7ffdae5582c0 is located in stack of thread T0 at offset 32 in frame
    #0 0x55afe3e30e03 in x11_display_server_destroy gfx/display_servers/dispserv_x11.c:472

  This frame has 1 object(s):
    [32, 57) 'dmode' (line 485) <== Memory access at offset 32 is inside this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: bad-free (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10d7cf) in __interceptor_free
==21941==ABORTING

Ah yes, sorry about that. I'm only testing on a CRT. This should be OK now.

Thanks for the help @bslenul. Please could you do one more test?

Doesn't crash anymore, but all the memory leaks are back :(

@bslenul Have you checked the memory leaks before my patch?

When compiling b4bbad4 (so without your PR) I "only" get this memory leak when closing RA:

==39802==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 176 byte(s) in 2 object(s) allocated from:
    #0 0x7fe0aff97bc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7fe0ae9e378a in pa_xmalloc (/usr/lib/x86_64-linux-gnu/libpulse.so.0+0x3b78a)

SUMMARY: AddressSanitizer: 176 byte(s) leaked in 2 allocation(s).

If that's what you're asking.

Still segfault here. I get this on an older machine (Thinkpad T420 with Intel Graphics). Not crashing on my gaming rig (Ryzen, Nvidia 1660). I guess has to do with video drivers...?

@DocMAX Yeah I've been making a fair few changes. Also you need to compile my patch to see the changes.

@bslenul I have removed all x11 related mem leaks now. I have tested with CRSwithres on and off. Please can you confirm this.

I don't think we talk about the same problem. Here is what i see on dmesg after segfault. Also although i compiled with make DEBUG=1 gdb says "no debug symbols found in retroarch".

[Fr Sep 11 20:30:11 2020] traps: retroarch[1206347] general protection fault ip:7fa692203089 sp:7fff156a6d28 error:0 in libGLX_mesa.so.0.0.0[7fa6921eb000+47000]

Edit: Here my glxinfo if of any interest:

name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) HD Graphics 3000 (SNB GT2) (0x126)
    Version: 20.1.7
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 3.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 3000 (SNB GT2)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 20.1.7
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 20.1.7
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.0 Mesa 20.1.7
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

@DocMAX I think you have some other issues there. Did you compile my PR?

@alphanu1 all good for me! No more crash on content load, and no more additional memory leak on close 👍

I did compile the PR.
Not good for me. Here is my debug log!
ra.log

Edit: I can see the crash on all my computers with Intel Graphics chipset (Thinkpad T420 and Carbon X1 3rd Gen). No issues on Nvidia hardware!
And again: It's only working with XMB!

OK now for the crazy part: If i delete the playlists, no crash!!!???!???

So i think you can reproduce this error if you grab an Intel Graphics Notebook (like me it's Intel Graphics 3000 and 5500), create at least 1 playlist and run. It will segfault with any driver except XMB!

OK, found a workaround. Changed
video_threaded =
from true to false and it works!

Threaded video has to work too though. If it doesnt then it means the code is not threadsafe, which is not good either way.

@twinaphex I honestly don't think the CRTSwitchRes code is the issue here now though.

OK, @jdgleaver is it possible you would be able to investigate these issues on Linux? It seems quite serious for stability.

@twinaphex I have compiled RetroArch with and without the CRTSwitchRes changes. I have done this on laptop with a 3rd gen intel CPU, GPU 3000+ HD.

I get a crash when trying to turn on Threaded video in both cased. ERROR- i965: Failed to submit batchbuffer

It seems this issue is not related to CRTSwitchRed

Alright, well, I very much would like to investigate these leaks first with @jdgleaver (he might be available on Monday again). As for the threaded video issues, either it's a Mesa bug or a fault in our codebase, we'll try to look at that too.

After we have investigated all this we can then decide to merge the CRT PR again.

@twinaphex I pulled fresh from the libretro git. I get the same i965 error. So, I would assume its a mesa bug

@bslenul confirmed I have removed the memory leaks. But yes double check first.

I'm afraid I won't have time to check the PR this weekend, but I will do so first thing on Monday. The crash when enabling threaded video is a very long standing issue, and as far as we can tell is a mesa bug - so probably unrelated to the changes here :)

But I will certainly give this a going over with ASAN, etc.

This all seems fine to me :)

  • No crashes with any gfx driver/menu driver combination

  • No crashes when toggling threaded video (when using nvidia gfx)

  • No crashes when automatically switching drivers on load content (via overrides)

  • No additional memory leaks

    • Pulse audio always leaks a few bytes anyway - that's not our fault

    • The Vulkan gfx driver is slightly leaky, but this is in the driver itself and happens on master as well (and always has)

    • The sdl2 gfx driver has quite a number of small leaks, but again this seems to happen in the sdl libraries and it's present on master as well

The crash when toggling threaded video on certain systems with intel gfx is unfortunate, but unrelated to this PR (and since it's a driver/mesa issue, there's not much we can do about it...)

@twinaphex Looks like #11323 is ready to go :)

OK, it's merged.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

fr500 picture fr500  ·  4Comments

orbea picture orbea  ·  3Comments

meepingsnesroms picture meepingsnesroms  ·  4Comments

hyarsan picture hyarsan  ·  4Comments

parkerlreed picture parkerlreed  ·  3Comments