mupen64plus-ui-python
mupen64plus-ui-python copied to clipboard
SDL2 version crashes on start with "arguments to dbus_connection_unref() were incorrect"
I just updated Mageia's m64py package to the new version 0.2.4, after packaging PySDL2 0.9.5. On startup I get a DBus-related error and it crashes.
M64Py - A frontend for Mupen64Plus version 0.2.4
Frontend: INFO: OpenGL_accelerate module loaded
Frontend: INFO: Using accelerated ArrayDatatype
Frontend: INFO: attached to library 'Mupen64Plus Core' version 2.5.0
Frontend: INFO: includes support for Dynamic Recompiler.
Core: Unable to open rom database file '(null)'.
Frontend: INFO: video extension enabled
Video: No version number in 'Rice-Video' config section. Setting defaults.
Video: Old parameter config version detected : 0, updating to 1;
Video: Couldn't find Glide64mk2.ini
Frontend: DEBUG: plugin_startup()
Frontend: WARNING: FILES: Error opening, creating, reading, or writing to a file
Frontend: WARNING: Glide64mk2 Video Plugin failed to start.
Input: Couldn't find config file 'InputAutoCfg.ini'
Input: missing 'plugged' parameter from config section AutoConfig0. Setting to 1 (true).
Input: missing 'plugin' parameter from config section AutoConfig0. Setting to 1 (none).
Input: missing config key 'DPad R' for controller 1 button 0
Input: missing config key 'DPad L' for controller 1 button 1
Input: missing config key 'DPad D' for controller 1 button 2
Input: missing config key 'DPad U' for controller 1 button 3
Input: missing config key 'Start' for controller 1 button 4
Input: missing config key 'Z Trig' for controller 1 button 5
Input: missing config key 'B Button' for controller 1 button 6
Input: missing config key 'A Button' for controller 1 button 7
Input: missing config key 'C Button R' for controller 1 button 8
Input: missing config key 'C Button L' for controller 1 button 9
Input: missing config key 'C Button D' for controller 1 button 10
Input: missing config key 'C Button U' for controller 1 button 11
Input: missing config key 'R Trig' for controller 1 button 12
Input: missing config key 'L Trig' for controller 1 button 13
Input: missing config key 'Mempak switch' for controller 1 button 14
Input: missing config key 'Rumblepak switch' for controller 1 button 15
Input: missing config key 'X Axis' for controller 1 axis 0
Input: missing config key 'Y Axis' for controller 1 axis 1
process 18809: arguments to dbus_connection_unref() were incorrect, assertion "connection->generation == _dbus_current_generation" failed in file dbus-connection.c line 2822.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace
Abandon (core dumped)
Going back to version 0.2.3 works fine.
Are you sure that going back to version 0.2.3 works? On same system, you are not running as root, same mupen64plus etc.? There is nothing special in 0.2.4, dbus in frontend is only used to enable/disable screensaver and nothing is changed there, not sure if any plugin is using dbus on Linux. Looks like Glide64mk2 can't start, it is missing .ini file.
Going back to 0.2.3 does work on the same system in the same conditions. The only difference is that it was packaged 6 months ago - I'll try building 0.2.3 anew with the same setup as 0.2.4 and see how it goes.
Rebuilt 0.2.3 and tried it, it still works fine. The log is quite similar, so the missing Glide64mk2 is another issue as it does not prevent startup (I might need to fix my mupen64plus package?):
M64Py - A frontend for Mupen64Plus version 0.2.3
Frontend: INFO: OpenGL_accelerate module loaded
Frontend: INFO: Using accelerated ArrayDatatype
Frontend: INFO: attached to library 'Mupen64Plus Core' version 2.5.0
Frontend: INFO: includes support for Dynamic Recompiler.
Core: Unable to open rom database file '(null)'.
Frontend: INFO: video extension enabled
Video: Couldn't find Glide64mk2.ini
Frontend: DEBUG: plugin_startup()
Frontend: WARNING: FILES: Error opening, creating, reading, or writing to a file
Frontend: WARNING: Glide64mk2 Video Plugin failed to start.
Video: No version number in 'Rice-Video' config section. Setting defaults.
Video: Old parameter config version detected : 0, updating to 1;
Input: Couldn't find config file 'InputAutoCfg.ini'
Input: missing 'plugged' parameter from config section AutoConfig0. Setting to 1 (true).
Input: missing 'plugin' parameter from config section AutoConfig0. Setting to 1 (none).
Input: missing config key 'DPad R' for controller 1 button 0
Input: missing config key 'DPad L' for controller 1 button 1
Input: missing config key 'DPad D' for controller 1 button 2
Input: missing config key 'DPad U' for controller 1 button 3
Input: missing config key 'Start' for controller 1 button 4
Input: missing config key 'Z Trig' for controller 1 button 5
Input: missing config key 'B Button' for controller 1 button 6
Input: missing config key 'A Button' for controller 1 button 7
Input: missing config key 'C Button R' for controller 1 button 8
Input: missing config key 'C Button L' for controller 1 button 9
Input: missing config key 'C Button D' for controller 1 button 10
Input: missing config key 'C Button U' for controller 1 button 11
Input: missing config key 'R Trig' for controller 1 button 12
Input: missing config key 'L Trig' for controller 1 button 13
Input: missing config key 'Mempak switch' for controller 1 button 14
Input: missing config key 'Rumblepak switch' for controller 1 button 15
Input: missing config key 'X Axis' for controller 1 axis 0
Input: missing config key 'Y Axis' for controller 1 axis 1
python2 vs python3 issue maybe? Check also version of dbus-python, I have no idea what else can be a issue. Try to start it as root, then it should print a warning that it can't connect to dbus session, so it should not try to use it.
It does work as root since the DBus session is not used indeed.
I build m64py with python3 and have dbus-python 1.2.4.
For the reference, my spec file:
# This should be pushed to tainted as per Mageia's policy on emulators
%define debug_package %{nil}
Name: m64py
Version: 0.2.4
Release: %mkrel 1
Summary: A Qt5 frontend for Mupen64Plus
License: GPLv3
Group: Emulators
Url: http://m64py.sourceforge.net
Source: http://sourceforge.net/projects/m64py/files/%{name}-%{version}/%{name}-%{version}.tar.gz
BuildRequires: python3-qt5-devel
BuildRequires: python3-sip
Requires: %{_lib}mupen64plus2 >= 2.0
Requires: %{_lib}sdl2.0_0
Requires: python3-dbus
Requires: python3-opengl
Requires: python3-qt5
Requires: python3-sdl2
Requires: python3-sip
%description
M64Py is a Qt5 front-end (GUI) for Mupen64Plus 2.0, a cross-platform
plugin-based Nintendo 64 emulator. The front-end is written in Python
and it provides a user-friendly interface over Mupen64Plus shared library.
%prep
%autosetup
%build
%py3_build
%install
%py3_install
%files
%doc AUTHORS ChangeLog COPYING LICENSES PKG-INFO README.md
%{_bindir}/%{name}
%{_datadir}/applications/%{name}.desktop
%{_datadir}/pixmaps/%{name}.png
%{python3_sitelib}/%{name}/
%{python3_sitelib}/%{name}-%{version}-py%{python3_version}.egg-info
It did not change significantly since 0.2.3, apart from adding python3-sdl2 as dependency (PySDL2).
I'll see if I can bisect the issue.
This is a part of code that use dbus on Linux to enable/disable screensaver https://github.com/mupen64plus/mupen64plus-ui-python/blob/master/src/m64py/screensaver.py#L24 . Nothing changed there for 2 years.
A bisect gave 68e6f392cf04c02ecd7855322b09f683959d3185 as first bad commit. Maybe 0.2.3 used to default to SDL1 on my system? IIUC it has some autodetect logic, right?
I confirm that 0.2.3 gives the same error when started with m64py --sdl2. Same error when installing the python 2 flavour too.
Libraries:
- Python 3.5.2 and 2.7.12
- SDL2 2.0.5
- PySDL2 0.9.5
- PyQt5 5.6
- dbus-python 1.2.4
SDL2 internaly use dbus on Linux but doesn't link to libdbus, instead it loads libdbus-1.so.3 https://hg.libsdl.org/SDL/file/e854440318d2/src/core/linux/SDL_dbus.c , so you can check that.
And now, without SDL1, frontend can just call https://wiki.libsdl.org/SDL_DisableScreenSaver , no need for screensaver.py at all.
I am getting the same problem in Fedora 25
M64Py - A frontend for Mupen64Plus version 0.2.4
Frontend: ERROR: None: cannot open shared object file: No such file or directory
Traceback (most recent call last):
File "/home/loganmc10/mupen64plus-GLideN64/mupen64plus-ui-python/src/m64py/core/core.py", line 88, in core_load
self.m64p = load(path)
File "/home/loganmc10/mupen64plus-GLideN64/mupen64plus-ui-python/src/m64py/loader.py", line 87, in load
raise ImportError(e)
ImportError: None: cannot open shared object file: No such file or directory
dbus[5502]: arguments to dbus_connection_ref() were incorrect, assertion "connection->generation == _dbus_current_generation" failed in file ../../dbus/dbus-connection.c line 2686.
This is normally a bug in some application using the D-Bus library.
dbus[5502]: arguments to dbus_connection_close() were incorrect, assertion "connection->generation == _dbus_current_generation" failed in file ../../dbus/dbus-connection.c line 2935.
This is normally a bug in some application using the D-Bus library.
Segmentation fault (core dumped)
Doesn't look like exactly the same error. You have this ImportError: None: cannot open shared object file: No such file or directory
Can you try to comment in screensaver.py everything related to dbus? Just to confirm who is throwing that error, python-dbus or SDL2->dbus.
Sorry that was just becuse I didn't have libmupen64plus.so in the right spot, I fixed that.
I commented out everything in def __init__(self) in screensaver.py and replacd it with print("hello")
the dbus error still happened
"hello" was printed to the screen, so I know that code executed
Ok, thanks. So if m64py doesn't touch dbus anymore then it must be SDL2 fault. Please also remove import dbus line, just to be sure. As I wrote above, SDL2 tries to open libdbus like this https://hg.libsdl.org/SDL/file/e854440318d2/src/core/linux/SDL_dbus.c , doesn't link to it.
I have SDL2 version 2.0.5 and dbus 1.10.14 and it works ok.
The import line was removed for my first test.
I'll do some more testing and see if I can figure out a solution
I'm on Fedora 25, I also have SDL2 2.0.5, but the dbus version is 1.11.8 (PySDL2 installed from pip, so I assume it's the latest version).
EDIT: I filed a bug with SDL2 https://bugzilla.libsdl.org/show_bug.cgi?id=3580, maybe they will be able to fix it
I haven't really tracked down what is causing this, but I get this same message in Ubuntu 16.04.
Although in Fedora 25, m64py closes instantly, in Ubuntu 16.04 m64py stays open and it works, but I get a ton of these dbus error messages in the terminal while it's running
Using Manjaro with the same problem.
I have the same problem on Manjaro as well. As an exercise I attempted to dig into it a little, but I admit that I am swimming in deep water and have yet to discover the cause (I am learning a lot though!)
However, in troubleshooting I did discover a workaround. If you rebuild/reinstall dbus and make sure the following options are passed to configure, the error goes away:
--disable-asserts --disable-checks
I don't know how much this information is worth, or what the possible consequences are of setting these options, but it's working for me currently. I don't really know what to do next but if anyone has any suggestions, or would like me to test something etc., I would be glad to help.
That is some clue. On Gentoo dbus is always built with --disable-asserts --disable-checks , so I never had that problem. Question is if this something that is enabled/forced on some distros since recently or they had that before and only now something (PySDL, PyQt, SDL) is triggering it.
Question is if this something that is enabled/forced on some distros since recently or they had that before and only now something (PySDL, PyQt, SDL) is triggering it.
They had it before. At least in Mageia nothing changed packaging-wise for dbus, and given the number of reports from other distros, it can't be a coincidence, so the issue is triggered by one of the new dependencies in 0.2.4 IMO.
There are no new dependencies in 0.2.4, PySDL2 is just unbundled from m64py source and must be installed now. I also tried with old PySDL2 sources on Fedora that were bundled and it doesn't help.
I know, but as I diagnosed above already, before 0.2.4 the issue only happened when forcing the use of SDL2. I'd make an educated guess that all users of distros reporting 0.2.4 as not working were using the SDL1 flavour previously. So by "new dependency", I mean the fact that as per 0.2.4 everybody is using SDL2, while previously the autodetect was most of the time landing on SDL1. So the issue needs to be investigated around SDL2, PySDL2 or related dependencies: https://github.com/mupen64plus/mupen64plus-ui-python/issues/91#issuecomment-274265403
To be clearer, the issue did not start with the unbundling of SDL2. It started with the removal of the SDL1 alternative.
I just recompiled my system dbus without --disable-asserts --disable-checks (modified ebuild) and it still works. Can someone try to remove SDL2 system lib and compile a new one from hg or latest tarball?
Any update for the average user?
Hey, I haven't tried mupen64, but I'm one of the SDL developers, and we're trying to get a reproduction case for this issue. Can anyone seeing this get a backtrace from the error so we can see where this happens?
We aren't sure if it's an SDL bug, an incompatibility between D-Bus versions, bad luck, etc.