We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3692

Summary: _XData32 SIGBUS at startup on OpenBSD/mips64el
Product: SDL Reporter: Donovan Watteau <contrib>
Component: *don't know*Assignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2    
Version: 2.0.5   
Hardware: Other   
OS: OpenBSD   

Description Donovan Watteau 2017-07-04 10:56:37 UTC
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.
Comment 1 Ryan C. Gordon 2017-07-05 00:37:16 UTC
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.
Comment 2 Ryan C. Gordon 2017-07-05 00:44:51 UTC
(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.
Comment 3 Donovan Watteau 2017-07-06 10:23:47 UTC
Yes, I can confirm that the crashes are gone with this change.

Thank you!