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 796 - Infinite loop in SDL_SYS_JoystickClose with QtSixAd & mednafen
Summary: Infinite loop in SDL_SYS_JoystickClose with QtSixAd & mednafen
Status: RESOLVED WONTFIX
Alias: None
Product: SDL
Classification: Unclassified
Component: joystick (show other bugs)
Version: 1.2.13
Hardware: x86 Linux
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-18 18:08 UTC by jarrod.b.johnson+sdlbugs
Modified: 2009-10-17 11:04 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description jarrod.b.johnson+sdlbugs 2009-09-18 18:08:40 UTC 
I'm running QtSixA to allow me to use my PS3 controller with my x86_64 linux system via bluetooth.  When I run mednafen and it exits, SDL's attempts to close the joystick enters an infinite loop.  Specifically:

        if (SDL_joylist[joystick->index].fname == NULL) {
                SDL_joylist_head(i, joystick->index);
                SDL_JoystickClose(SDL_joylist[i].joy);
        }


It enters this conditional where joystick looks like this:
(gdb) print *joystick
$9 = {index = 0 '\0', name = 0x0, naxes = 18, axes = 0x1d951e0, nhats = 4, 
  hats = 0x1d92ff0 "", nballs = 0, balls = 0x0, nbuttons = 21, 
  buttons = 0x1d93010 "", hwdata = 0x1d952f0, ref_count = 0}

and SDL_joylist at 0 is:
(gdb) print SDL_joylist[0]
$7 = {fname = 0x0, joy = 0x1d95280, map = 0x0, prev = 0, next = 0, 
  logicalno = 0}

So:
#define SDL_joylist_head(i, start)\
        for(i = start; SDL_joylist[i].fname == NULL;) i = SDL_joylist[i].prev;

That loop starts with i==0, fname is indeed NULL, and prev is also zero, making this an infinite loop.  

My first guess at how to proceed would be for it to look like:
for(i = start; SDL_joylist[i].fname == NULL && i != SDL_joylist[i].prev;)  \
  i = SDL_joylist[i].prev;


However, I'm not sure if that would break assertions made by code following invocations of that #define.
Comment 1 jarrod.b.johnson+sdlbugs 2009-09-18 18:24:17 UTC 
Yes, my quick guess is insufficient, all the code following that check very much is not expecting for that loop to come back empty-handed, and will segfault.
Comment 2 Sam Lantinga 2009-09-28 02:58:03 UTC 
I just tried this with QtSixA 0.4.3 on Ubuntu 9.04 x86_64 and it worked just fine:
$ ./testjoystick 
There are 1 joysticks attached
Joystick 0: Sony PLAYSTATION(R)3 Controller
       axes: 27
      balls: 0
       hats: 0
    buttons: 19

Are you still having trouble with the latest SDL snapshot?
http://www.libsdl.org/tmp/SDL-1.2.zip

Interestingly I wasn't able to get it working in Bluetooth mode, only via USB.
Comment 3 jarrod.b.johnson+sdlbugs 2009-09-28 11:31:57 UTC 
I will try again with latest snapshot, however, I also had no problems in USB mode, only bluetooth mode.

In the meantime, one question is can it ever possibly make sense for the fname member of the struct to be null (i.e. is something about the way sixad daemon relays events to the joystick device a valid case for fname being null).  Or perhaps is mednafen ultimately doing something wrong/unexpected (i.e. calling close twice?)  Is there some code before that point that is intended to protect that loop from seeing that condition, or does that loop need to not loop infinitely when the loop conditions currently cause it to?
Comment 4 Sam Lantinga 2009-09-28 17:04:16 UTC 
A good test would be to try testjoystick in the SDL snapshot archive.  That at least will tell you whether it's something silly like a double-close (which shouldn't ever be done!)

Also, would it be possible for me to log in remotely and debug?  If so, please send me login information via private e-mail.
Comment 5 Sam Lantinga 2009-10-17 11:04:41 UTC 
No response from the customer, I'm closing this for now.  Please reopen this as a 1.3 bug if it's an issue there.