FS#74214 - mame bgfx problem, core dump

Attached to Project: Community Packages
Opened by Thomas (tomsam) - Wednesday, 23 March 2022, 18:07 GMT
Last edited by Antonio Rojas (arojas) - Friday, 01 April 2022, 08:18 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Antonio Rojas (arojas)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



Until the previous version, mame worked fine on my usually updated Arch system.

Linux warp 5.16.15-arch1-1 #1 SMP PREEMPT Thu, 17 Mar 2022 00:30:09 +0000 x86_64 GNU/Linux

Now with version

mame 0.241-1

it displays the text

$ mame
Unable to open effect file bgfx/effects/gui_opaque.json
Unable to open effect file bgfx/effects/gui_blend.json
Unable to open effect file bgfx/effects/gui_multiply.json
Unable to open effect file bgfx/effects/gui_add.json
Unable to open effect file bgfx/effects/screen_opaque.json
Unable to open effect file bgfx/effects/screen_blend.json
Unable to open effect file bgfx/effects/screen_multiply.json
Unable to open effect file bgfx/effects/screen_add.json
Ignoring MAME exception: BGFX: Unable to load required shaders. Please check and reinstall the bgfx folder

Fatal error: BGFX: Unable to load required shaders. Please check and reinstall the bgfx folder

Memory fault(coredump)

at startup.

Reinstallation of the package, and removing the mame.ini file, did not help.

The question is: Is this a bug or is there just a new config option missing

The bgfx files (from the package) seems to be installed

find /usr/lib/mame/bgfx/ -ls | wc -l

find /usr/lib/mame/artwork/bgfx -ls | wc -l

ls -l /usr/share/doc/mame/source/advanced/bgfx.rst
-rw-r--r-- 1 root root 7868 23. Feb 21:17 /usr/share/doc/mame/source/advanced/bgfx.rst

I.e. 1462 file with bgfx in it, just like in the files list.

The files (here shown for the files with opaque in the name)
mame claimed not to be able to find are also there:

find /usr/lib/mame/bgfx/ -ls | grep opaque
36707782 4 -rw-r--r-- 1 root root 599 Feb 23 21:17 /usr/lib/mame/bgfx/effects/gui_opaque.json
36707786 4 -rw-r--r-- 1 root root 677 Feb 23 21:17 /usr/lib/mame/bgfx/effects/screen_opaque.json

If you need more information about my system, let me know.

Additional info:
* package version(s)
mame 0.241-1

* config and/or log files etc.
* link to upstream bug report, if any

Steps to reproduce:

Start mame

This task depends upon

Closed by  Antonio Rojas (arojas)
Friday, 01 April 2022, 08:18 GMT
Reason for closing:  Fixed
Additional comments about closing:  mame 0.242
Comment by Antonio Rojas (arojas) - Friday, 25 March 2022, 10:45 GMT
Please test with 0.240 to make sure this is actually caused by the mame upgrade and not some other changes in the graphics stack
Comment by Thomas (tomsam) - Friday, 25 March 2022, 16:18 GMT
sudo pacman -U /var/cache/pacman/pkg/mame-0.240-1-x86_64.pkg.tar.zst

and mame works well.
Comment by Antonio Rojas (arojas) - Friday, 25 March 2022, 18:15 GMT
ok, please report it upstream then. There are no packaging changes between 0.240 and 0.241
Comment by Thomas (tomsam) - Sunday, 27 March 2022, 19:10 GMT

At Upstream nobody cares about the issue. The only thing that happened until now is that they changed the subject in a way, that it is clear that they assume this to be an arch problem not a general one.

Meanwhile I compiled the original 0.241-1 sources (just by make -j 4), and the resulting executable (429865120 bytes in size) works correctly right from the start!

Just calling the arch package /usr/lib/mame/mame (263496160 bytes in size) produces the above mentioned errors.

Then I found out that /bin/mame is not the executable itself, but a shell script (whoever the original author of this script might be)

This script does not keep in mind that a $HOME/.mame could already exist and that it may not contain all the directories listed in the mame_first_run() or not all the options that would otherwise be generated in that run.

Creating the corresponding directories and running package mame with --newini creates a config file that works, leaving the work of copying old settings to the new ini file to the user.

The self-compiled version does create a new .mame and a ui.ini if .mame is not present, while the /usr/lib/mame/mame of the package does not (and crashes).

Note: If I strip my self-compiled mame executable, it results in 344724992 bytes __AND__ from then on it behaves wrongly, too ! So most probably the whole issue is caused by delivering a stripped executable.

Comment by Thomas (tomsam) - Tuesday, 29 March 2022, 07:02 GMT
According to the mametesters answer:

This issue has been around for a time. It has now been exposed
on 0.241 version because of this commit:

In short, MAME crashed if bgfx_path is not found. You can workaround
it by modifying your mame.ini:

bgfx_path /usr/lib/mame/bgfx

Anyway it is fixed here:

The problem results from an unchecked access
to the content of bgfx_path (in the config file).

So to be able to reproduce it, just set "bgfx_path=bgxxx"
in your config file and start the executable.


Besides others, they changed the file


Line 117 must be something like

error = renderer_bgfx::init(machine());

now (before it was without the "error = ").

I compiled the new version, and both, the non-stripped as well
as the stripped version work. The stripped version prints
the additional message

Unable to find the BGFX path bgfx, please install
it or fix the bgfx_path setting to use the BGFX

in this case.

I guess, this means, the package has to be rebuilt.