Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

_XData32 SIGBUS at startup on OpenBSD/mips64el #2493

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 0 comments
Closed

_XData32 SIGBUS at startup on OpenBSD/mips64el #2493

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.5
Reported for operating system, platform: OpenBSD, Other

Comments on the original bug report:

On 2017-07-04 10:56:37 +0000, Donovan Watteau wrote:

This is on OpenBSD/loongson -current, a mips64el architecture (64-bit MIPS, little-endian, LP64, strict-alignment). X is Xorg 1.18.4, libX11 1.6.5.

ScummVM, compiled with SDL2 (SDL 1.2 apps look OK on the same device), gives either a SIGBUS or a "No available display!" error right at startup, which looks random.

For example, here's what is happening in gdb when there's a SIGBUS:

(gdb) run
Starting program: /usr/local/bin/scummvm
WARNING: SDL mixer output buffer size: 882 differs from desired: 4096!

Program received signal SIGBUS, Bus error.
0x0000000a2bc625d0 in _XData32 () from /usr/X11R6/lib/libX11.so.16.1
(gdb) bt

0 0x0000000a2bc625d0 in _XData32 () from /usr/X11R6/lib/libX11.so.16.1

1 0x0000000a2bc320a4 in XChangeProperty () from /usr/X11R6/lib/libX11.so.16.1

2 0x00000009b2decdd4 in X11_CreateWindow (_this=0x9f4e81000,

window=0xa08a47b00)
at /usr/ports/pobj/sdl2-2.0.5/SDL2-2.0.5/src/video/x11/SDL_x11window.c:572

3 0x00000009b2ddab64 in SDL_CreateWindow_REAL (title=0xa1b1f8ca8 "ScummVM",

x=536805376, y=536805376, w=640, h=400, flags=0)
at /usr/ports/pobj/sdl2-2.0.5/SDL2-2.0.5/src/video/SDL_video.c:1442

4 0x00000009b2d36a08 in SDL_CreateWindow (a=Variable "a" is not available.

) at SDL_dynapi_procs.h:546

5 0x000000053dbe397c in SdlWindow::createWindow ()

from /usr/local/bin/scummvm

6 0x000000053f0f0a88 in SurfaceSdlGraphicsManager::SDL_SetVideoMode ()

from /usr/local/bin/scummvm

7 0x000000053f0f0dc4 in SurfaceSdlGraphicsManager::loadGFXMode ()

from /usr/local/bin/scummvm

8 0x000000053f0ea1f0 in SurfaceSdlGraphicsManager::endGFXTransaction ()

from /usr/local/bin/scummvm

9 0x000000053dbe4fc8 in _ZL13setupGraphicsR7OSystem ()

from /usr/local/bin/scummvm

10 0x000000053dbe5c8c in scummvm_main () from /usr/local/bin/scummvm

11 0x0000000000000000 in ?? ()

(gdb) bt full

0 0x0000000a2bc625d0 in _XData32 () from /usr/X11R6/lib/libX11.so.16.1

No symbol table info available.

1 0x0000000a2bc320a4 in XChangeProperty () from /usr/X11R6/lib/libX11.so.16.1

No symbol table info available.

2 0x00000009b2decdd4 in X11_CreateWindow (_this=0x9f4e81000,

window=0xa08a47b00)
at /usr/ports/pobj/sdl2-2.0.5/SDL2-2.0.5/src/video/x11/SDL_x11window.c:572
    data = (SDL_VideoData *) 0x9f521e800
    displaydata = Variable "displaydata" is not available.

It probably crashes around here, in src/video/x11/SDL_x11window.c:

/* Let the window manager know what type of window we are. */
_NET_WM_WINDOW_TYPE = X11_XInternAtom(display, "_NET_WM_WINDOW_TYPE", False);
wintype = X11_XInternAtom(display, wintype_name, False);
X11_XChangeProperty(display, w, _NET_WM_WINDOW_TYPE, XA_ATOM, 32,
PropModeReplace, (unsigned char *)&wintype, 1);

_NET_WM_BYPASS_COMPOSITOR = X11_XInternAtom(display, "_NET_WM_BYPASS_COMPOSITOR", False);
X11_XChangeProperty(display, w, _NET_WM_BYPASS_COMPOSITOR, XA_CARDINAL, 32,
PropModeReplace,
(unsigned char *)&compositor, 1);

This looks a bit similar to this GTK+ bug:
https://lists.debian.org/debian-x/2017/01/msg00287.html

Please tell me if you need any more information.

On 2017-07-05 00:37:16 +0000, Ryan C. Gordon wrote:

We do some tapdancing with X11 symbols to dynamically load it. I guess my recommendation would be:

  • Build SDL with "./configure --disable-x11-shared" and see if the problem just goes away. If it does, it's probably our dynamic loading code. It's probably reasonable to believe this system will always have X11 support, so maybe this as far as you have to go.

  • If it's our dynamic loading code and you want to debug this, it's almost certainly the "LONG64" thing in src/video/x11/SDL_x11sym.h ... this isn't a public API in Xlib, but rather a function that a public macro uses in Xlib's headers on some systems. Can you see if a) LONG64 is actually defined (it probably should be on this platform) and b) that the _XData32 function in /usr/include/X11/Xlibint.h (or wherever this is located for OpenBSD) matches what's in SDL_x11sym.h

  • Failing all this: can I get ssh access to the machine so I can debug this?

Thanks,
--ryan.

On 2017-07-05 00:44:51 +0000, Ryan C. Gordon wrote:

(In reply to Ryan C. Gordon from comment # 1)

We do some tapdancing with X11 symbols to dynamically load it. I guess my
recommendation would be:

No, wait, it's not that. The GTK+ bug report is exactly the same issue.

The patch I just made in https://hg.libsdl.org/SDL/rev/97c66d81b2c9 should fix this.

--ryan.

On 2017-07-06 10:23:47 +0000, Donovan Watteau wrote:

Yes, I can confirm that the crashes are gone with this change.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant