Using Linux. Whenever I try to load one of those MegaBezel shaders unfortunately RA just hangs here. It takes all the CPU and stays blocked.
I have to forcefully kill the program. Tried a couple of different shaders presets to no avail.
Running this version of RA:
RetroArch: Frontend for libretro – v1.10.3 – 9b282aa742 – Compiler: GCC (9.4.0) 64-bit Built: Apr 22 2022
Thank you for any help!
Update. This happens either with the Vulkan or glcore drivers.
Also, it’s not only related to the Mega Bezels shaders apparently but also to CRT Royale, that is, any heavy shaders.
What can I do to get around this? I would eventually expect the game to stutter and run with an unplayable framerate, but not for RetroArch to hang up completely.
Many thanks!
Hi,
I reproduced also the issue using latest b793169.
Using ASAN,
make DEBUG=1 SANITIZER=address,undefined
I got those logs
MBZ_3_STD_slangp
deps/glslang/glslang/glslang/MachineIndependent/localintermediate.h:92:8: runtime error: load of value 144, which is not a valid value for type 'bool'
deps/glslang/glslang/glslang/MachineIndependent/localintermediate.h:92:8: runtime error: load of value 85, which is not a valid value for type 'bool'
deps/glslang/glslang/glslang/MachineIndependent/localintermediate.h:92:8: runtime error: load of value 189, which is not a valid value for type 'bool'
crt-royale.slangp
=================================================================
==61059==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffe0ae628c0 at pc 0x559baf4a4364 bp 0x7ffe0ae626f0 sp 0x7ffe0ae626e0
READ of size 1 at 0x7ffe0ae628c0 thread T0
#0 0x559baf4a4363 in rhmap_hash_string libretro-common/include/array/rhmap.h:155
#1 0x559baf4affb1 in config_get_entry libretro-common/file/config_file.c:972
#2 0x559baf4b15b7 in config_get_bool libretro-common/file/config_file.c:1200
#3 0x559bb022023d in video_shader_parse_textures gfx/video_shader_parse.c:468
#4 0x559bb022c133 in video_shader_load_root_config_into_shader gfx/video_shader_parse.c:1635
#5 0x559bb022d539 in video_shader_load_preset_into_shader gfx/video_shader_parse.c:1846
#6 0x559bb01611b7 in gl3_filter_chain_create_from_preset gfx/drivers_shader/shader_gl3.cpp:2226
#7 0x559bb011ad2b in gl3_init_filter_chain_preset gfx/drivers/gl3.c:977
#8 0x559bb012133d in gl3_set_shader gfx/drivers/gl3.c:1652
#9 0x559bb0232050 in apply_shader gfx/video_shader_parse.c:2527
#10 0x559bafc9a07e in menu_shader_manager_set_preset menu/menu_driver.c:7331
#11 0x559bafcae500 in generic_action_ok menu/cbs/menu_cbs_ok.c:2040
#12 0x559bafcafb83 in action_ok_shader_preset_load menu/cbs/menu_cbs_ok.c:2276
#13 0x559bafca0225 in generic_menu_entry_action menu/menu_driver.c:7889
#14 0x559bafa70f9b in xmb_menu_entry_action menu/drivers/xmb.c:4316
#15 0x559bafc76619 in menu_entry_action menu/menu_driver.c:4315
#16 0x559bafc9d2db in generic_menu_iterate menu/menu_driver.c:7684
#17 0x559bafca238e in menu_driver_iterate menu/menu_driver.c:8097
#18 0x559baf1c9b69 in runloop_check_state /tmp/RetroArch/runloop.c:6876
#19 0x559baf1d31cd in runloop_iterate /tmp/RetroArch/runloop.c:7661
#20 0x559baf173074 in rarch_main /tmp/RetroArch/retroarch.c:3858
#21 0x559baf173147 in main /tmp/RetroArch/retroarch.c:3943
#22 0x7fca8c938082 in __libc_start_main ../csu/libc-start.c:308
#23 0x559baf140f7d in _start (/tmp/RetroArch/retroarch+0x49bcf7d)
Address 0x7ffe0ae628c0 is located in stack of thread T0 at offset 160 in frame
#0 0x559bb021f2e3 in video_shader_parse_textures gfx/video_shader_parse.c:407
This frame has 7 object(s):
[32, 33) 'mipmap' (line 434)
[48, 49) 'smooth' (line 435)
[64, 72) 'save' (line 410)
[96, 160) 'id_filter' (line 431) <== Memory access at offset 160 overflows this variable
[192, 256) 'id_wrap' (line 432)
[288, 352) 'id_mipmap' (line 433)
[384, 4480) 'texture_path' (line 412)
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: stack-buffer-overflow libretro-common/include/array/rhmap.h:155 in rhmap_hash_string
Shadow bytes around the buggy address:
0x1000415c44c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000415c44d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000415c44e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000415c44f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000415c4500: 00 00 00 00 f1 f1 f1 f1 01 f2 01 f2 00 f2 f2 f2
=>0x1000415c4510: 00 00 00 00 00 00 00 00[f2]f2 f2 f2 00 00 00 00
0x1000415c4520: 00 00 00 00 f2 f2 f2 f2 00 00 00 00 00 00 00 00
0x1000415c4530: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
0x1000415c4540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000415c4550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000415c4560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==61059==ABORTINGThanks for checking this out!
lol I was just writing to say “still hanging here” when it finally finished compiling. Seems fine now.
Hey guys thanks! Will give it a try. Hope my laptop is powerful enough to build retroarch in a decent amount of time.
Thanks!!
Wasn’t able to build RA with the fix yet, but wanted to add what I just noticed.
The same behaviour described in the original posts also happens in Android!
Hope this is useful.
Thank you so much for your support.
I was not able to build RA unfortunately, but I just installed the latest nightly build on android and the behaviour is still there. The app hangs and then the OS me asks if I want to kill it as “it’s not responding”.
Hope this helps,
Many thanks!
I suspect for Android it’s just a matter of it taking a long time to compile and the OS thinking it’s frozen.
The fix should be in the latest nightly builds, so you can try one of those instead of having to build it yourself.
Thanks for your reply. The behaviour happened with today’s build indeed 
Do you mean a fix should be available by tomorrow?
Thank you very much!
No, the fix was in a few days ago when I first reported that it started working for me again. Unless it’s broken again somehow.
If you’re basing it on the performance in Android, that’s probably just Android being Android. It used to give us ANR “kill the app?” warnings all the time while large games were loading, etc.
I’ve being able to install the latest build via “snap”. Unfortunately importing the configuration from the “apt” version didn’t work and I have to reconfigure everything from scratch apparently (FIY).
That being said, unfortunately it’s not working still. Behaviour’s the same. Build date’s yesterday:
Thank you very much! 
