Re: mednafen 0.9.39.2 -> 0.9.46

On 2017-08-13 23:44:55, Jeremy Evans <jeremyevans0@gmail.com> wrote:
> >
> > With that patch, mednafen 0.9.46 now works even when a gamepad is
> > plugged in. But I can't get mednafen to recognize the gamepad; it
> > doesn't let me map any of its keys.
> >
> > Also, I can say that mgba (the sdl version) has the same problem as the
> > unpatched mednafen. If a controller is plugged in, it shows only a black
> > screen and has to be killed. Works fine without a controller.
> >
>
> It certainly appears as though this is an issue in sdl or below. Looking
> at the devel/sdl history, there's no recent changes to it. I tried
> recompiling mednafen and sdl with gcc to make sure it isn't a compiler
> issue, but got the same results. The problem may be lower level. I'd like
> to look into this, but I probably won't have the necessary time for a few
> months. If anyone else can work on it before then, I'd appreciate it.
>

I can confirm seeing this in other SDL programs too. dgen (SDL1),
desmume (SDL1), mgba (SDL2), fceux (SDL1), and retroarch (SDL2)
all display the same symptoms.

I tried to do some basic digging, but didn't have much luck. I
noticed that there's an SDL_malloc() call right before joystick
initialization occurs in SDL1.

Thinking that this as good a place to start as any, I patched
SDL_malloc() to just call malloc() directly but it didn't change
the behavior at all.

So then I tried to get a better backtrace, and got the following
from desmume:

[Switching to thread 521665]
futex () at -:3
3 -: No such file or directory.
in -
Current language: auto; currently asm
(gdb) bt
#0 futex () at -:3
#1 0x000005e1e50f5f85 in _rthread_cond_timedwait
(cond=0x5e1e5d8a4f0,
mutexp=0x5e169916990, abs=0x0)
at /usr/src/lib/librthread/rthread_cond.c:106
#2 0x000005df312ea13b in _ZL8taskProcPv (arg=0x5e169916980)
at utils/task.cpp:219
#3 0x000005e1e50f7b9e in _rthread_start (v=Variable "v" is not available.)
at /usr/src/lib/librthread/rthread.c:115
#4 0x000005e22b79460b in __tfork_thread ()
at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75
#5 0x0000000000000000 in ?? ()
(gdb)

This seemed to point a finger at the new futex implementation, but
reverting the only recent commit there didn't change the behavior
at all.

So next I looked at utils/task.cpp:219 which is the following:

pthread_cond_wait(&ctx->condWork, &ctx->mutex);

So based on that and the rest of the above backtrace, as well as
the backtrace from mednafen previously posted in the thread which
was the following:

Thread 2 (thread 532442):
#0 _thread_sys_read () at -:3
#1 0x000000021b23400f in _libc_read_cancel (fd=Variable "fd" is not available.)
at /usr/src/lib/libc/sys/w_read.c:27
#2 0x00000002618d445d in SDL_SYS_JoystickUpdate () from
/usr/local/lib/libSDL.so.8.0
#3 0x00000002618b9a35 in SDL_JoystickUpdate () from
/usr/local/lib/libSDL.so.8.0
#4 0x00000000008ea7bb in __register_frame_info ()

It seems like looking at librthread would be the next logical
place. Digging around in the CVS history, there were a lot of
recent commits to try testing and reverting though.

If I can find the time, I'll try to see if I can bisect it by date
at the very least, but if someone else wants to beat me to it,
please be my guest! :)

--
Bryan