Linux : Segfault when trying to use any OnePAD plugin

[7oxicshadow]

PCSX2 version: 1.5.0-dev-2233-gbc8d9d40b

PCSX2 options: N/A

Plugins used: Any OnePAD plugin

Description of the issue: Pressing config on any OnePAD plugin causes segfault. If I try to launch a game I also get the following error:

../common/src/Utilities/Linux/LnxHostSys.cpp(70) : assertion failed: Function: void SysPageFaultSignalFilter(int, siginfo_t, void) Thread: EE Core Condition: false Message: Unhandled page fault @ 0x00000000

Stacktrace: [00] SysPageFaultSignalFilter(int, siginfo_t, void) LnxHostSys.cpp:0 [01] __kernel_rt_sigreturn
[02] strlen
[03] 0x0xefcbcee6
[04] 0x0xefcbd132
[05] PADopen
[06] SysCorePlugins::OpenPlugin_PAD()
[07] SysCorePlugins::Open(PluginsEnum_t)
[08] SysCorePlugins::Open()
[09] AppCorePlugins::Open()
[10] AppCoreThread::OnResumeInThread(bool)
[11] SysThreadBase::StateCheckInThread()
[12] SysCoreThread::StateCheckInThread()
[13] SysCoreThread::ExecuteTaskInThread()
[14] Threading::pxThread::_try_virtual_invoke(void (Threading::pxThread::)()) [15] Threading::pxThread::_internal_execute()
[16] Threading::pxThread::_internal_callback(void) [17] 0x0xf66e7577
[18] clone

How to reproduce the issue: Try to configure any OnePAD plugin on Linux

Last known version to work: Unknown

PC specifications: Fedora 27, i7 @ 4.5Ghz, 16GB Ram, GTX1070 using prop driver

[willkuer]

Lilypad works?

[7oxicshadow]

If i select lillypad the game loads fine but I have no controls. If i try to configure the plugin i get the following in the console:

Suspending single plugin: PAD Saving PAD Recovering single plugin: PAD Loading PAD

but no configuration window opens so I cannot configure the pad. I think I have seen Gregory mention in the past that lillypad is a work in progress and currently has no UI (unless things have changed recently)

[willkuer]

Yes it has no UI and thus can not easily be configured. I just wanted to know if onepad is really the issue.

Can you try older versions of onepad/pcsx2 if available?

[gregory38]

The issue is likely a wrongly compiled plugin. The SDL version of onepad must match the SDL version of wxwidget

[7oxicshadow]

I run build.sh with the following:

./build.sh --clean --release -DSDL2_API=FALSE --gtk3

This builds with no problems and creates the following plugins:

libcdvdGigaherz.so libCDVDnull.so libdev9null-0.5.0.so libFWnull-0.7.0.so libGSdx.so libLilyPad-0.11.0.so libonepad-legacy.so libspu2x-2.0.0.so libUSBnull-0.7.0.so

I have the libonepad-legacy plugin selected within PCSX2.

I use xboxdrv instead of xpad as it provides more customisation options. I have discovered that if I try to customise onepad without xboxdrv running it will open the configuration window fine BUT if I try to open the onepad configuration with xboxdrv running it will cause the application to close with a segfault.

I have been using xboxdrv with onepad for a long time so I know this setup has been working well in the past.

I have recently upgraded to Fedora 27 from Fedora 25 (clean install) so I am unsure if xboxdrv has received any new updates that breaks compatibility?

[gregory38]

Hum, do you have SDL debug symbol installed ? Goal is to find where are the frame 3 and 4.

[00] SysPageFaultSignalFilter(int, siginfo_t*, void*) LnxHostSys.cpp:0
[01] __kernel_rt_sigreturn
[02] strlen
[03] 0x0xefcbcee6
[04] 0x0xefcbd132
[05] PADopen

[7oxicshadow]

Hopefully this helps. Starting to wonder if its a name length issue?

Thread 1 "PCSX2" received signal SIGSEGV, Segmentation fault.
0xf11be6ad in std::char_traits<char>::length (__s=0x0)
    at /usr/include/c++/7/bits/char_traits.h:320
320     return __builtin_strlen(__s);

(gdb) bt
#0  0xf11be6ad in std::char_traits<char>::length(char const*) (__s=0x0)
    at /usr/include/c++/7/bits/char_traits.h:320
#1  0xf11be6ad in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::assign(char const*) (__s=0x0, this=0xafd1164)
    at /usr/include/c++/7/bits/basic_string.h:1418
#2  0xf11be6ad in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::operator=(char const*) (__s=0x0, this=0xafd1164)
    at /usr/include/c++/7/bits/basic_string.h:693
#3  0xf11be6ad in JoystickInfo::Init(int) (this=0xafd1160, id=0)
    at ../plugins/onepad_legacy/SDL/joystick.cpp:189
#4  0xf11be5df in JoystickInfo::EnumerateJoysticks(std::vector<GamePad*, std::allocator<GamePad*> >&) (vjoysticks=std::vector of length 1, capacity 1 = {...})
    at ../plugins/onepad_legacy/SDL/joystick.cpp:79
#5  0xf11be064 in GamePad::EnumerateGamePads(std::vector<GamePad*, std::allocator<GamePad*> >&) (vgamePad=std::vector of length 1, capacity 1 = {...})
    at ../plugins/onepad_legacy/GamePad.cpp:23
#6  0xf11c3546 in Dialog::InitDialog() (this=0xffffb32c)
    at ../plugins/onepad_legacy/Linux/dialog.cpp:295
#7  0xf11c517e in DisplayDialog() ()
    at ../plugins/onepad_legacy/Linux/dialog.cpp:638
#8  0xf11c6c43 in PADconfigure() ()
    at ../plugins/onepad_legacy/Linux/linux.cpp:201
#9  0x0824d3c1 in Panels::PluginSelectorPanel::OnConfigure_Clicked(wxCommandEven-

[gregory38]

Ok. I see.

[7oxicshadow]

I have been playing around with this issue for my own curiosity.

if you change "devname = SDL_JoystickName(id);" in /onepad_legacy/joystick.cpp to use a local variable instead of devname it gets further but still crashes.... (Note: The function appears to return "null" when printed)

The next crash is caused by line 168 "if (SDL_JoystickOpened(_id) )" in /onepad_legacy/joystick.cpp.

I can't explain that one as it takes a single integer in and should return true or false. If tried hard coding it to "0" instead of _id but it still crashes???

For the time being commenting out the following lines allows the plugin to function normally: "devname = SDL_JoystickName(id);" "if (SDL_JoystickOpened(_id) )"

Whilst it could result in unexpected behaviour its a temporary workaround until a proper fix is found.

[7oxicshadow]

I have just discovered that the workaround I mentioned above works great using "--debug" build flag but still crashes if i use "--release".

Optimization?

[gregory38]

Sorry I'm too busy. If devname is null we should early exit. It seems your pad isn't detected well by kernel or SDL

[gregory38]

Hum, there are 2 possibilities for first devname crash. Either we replace the null pointer with an empty string or we don't initialize this joystick. In first case, it seems we will have a crash later (my guess is that joy wasn't really opened correctly). In the 2nd case, you wan't be able to use your joystick.

[gregory38]

@7oxicshadow could you test the PR #2252 ? Thanks

[7oxicshadow]

Thanks for taking a look at this. Sadly it does not stop the crash but something odd is happening....

I have deleted my source so that I am starting a clean build. I pull the latest sources I get the updated file in PR #2252 I build with the following command "./build.sh --clean --release -DSDL2_API=FALSE --gtk3" Open PCSX2 Select Onepad Legacy Apply Press "Configure..." The App Crashes

Now this is where things get interesting....

I do all of the above steps but I build with the following command: "./build.sh --clean --debug -DSDL2_API=FALSE --gtk3"

I can configure my pad, Go in-game and play fine???

This means that I cannot get a backtrace because the debug build works?

[turtleli]

wxWidgets in Fedora 27 is compiled against SDL2.

Try compiling using just ./build.sh --clean --release --gtk3. I think you'll need to comment/delete the WX_vs_SDL() line in cmake/SearchForStuff.cmake beforehand (line 195, near the end of file).

[7oxicshadow]

@turtleli That was a good call. I have tried your suggestion and both onepad-legacy and onepad both work as expected with no crashes.

Does this suggest that is an SDL mismatch between Fedora's libraries and the build options with PCSX2?

[turtleli]

Well, the PCSX2 cmake scripts assumed that if wxWidgets is linked to SDL it is linked to 1.2, not 2. This assumption isn't true with Fedora 27. The cmake scripts will need to be updated to account for this.

[gregory38]

@turtleli. Thanks for the help. You're right, cmake must be updated. Maybe we can rely on lsb_release -r -s to query the fedora version.

[turtleli]

lsb_release might not be present (it's not there on my Fedora VM). This is what's in /etc/os-release though.

NAME=Fedora
VERSION="27 (Workstation Edition)"
ID=fedora
VERSION_ID=27
PRETTY_NAME="Fedora 27 (Workstation Edition)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:27"
HOME_URL="https://fedoraproject.org/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=27
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=27
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Workstation Edition"
VARIANT_ID=workstation

[7oxicshadow]

would "uname -r" be of any use for querying or "cat /etc/fedora-release"?

[turtleli]

uname -r wouldn't be useful since that outputs the kernel release. /etc/fedora-release might be useful.

Fedora release 27 (Twenty Seven)

The best thing to do would probably be to check what SDL version the wxWidgets libraries are actually linked against (if they are linked to SDL) - if other distros decide to link wxWidgets to SDL2 as well then it'll need fixed again.

[gregory38]

IMHO, the generic /etc/os-release is better. However if we have a way to find the SDL version it would be nice. Maybe an objdump or a ldd on wx can help.