The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
Memory corruption problem with SDL2 and joysticks
Watusimoto
Guest

Hello,

I'm having a very strange problem with joysticks in SDL2, using a build
of SDL based on code downloaded this evening. I'm working on Windows,
and built with the VC++ 10 EE project.

When I have a joystick plugged into my game, I get weird and semi-random
crashes that have all the hallmarks of a memory corruption issue,
something like a double-delete or related fault.

The overall program is fairly complex, but what we do is this, essentially:

1) Grab a joystick:

sdlJoystick = SDL_JoystickOpen(0); // only place sdlJoystick is
assigned
if(sdlJoystick == NULL) { /* error handling that is never triggered */ }

We can use this joystick for playing, and everything works fine. Until,
that is, we try to reacquire the joysticks (which we do to see if a user
has plugged a new stick in):

// [A] Close if already open
if(sdlJoystick)
{
TNLAssert(SDL_JoystickGetAttached(sdlJoystick), "Problem! --
never triggered");
SDL_JoystickClose(sdlJoystick);
sdlJoystick = NULL;
}

// [B] Will need to shutdown and init, to allow SDL_NumJoysticks to
count new joysticks
if(SDL_WasInit(SDL_INIT_JOYSTICK))
SDL_QuitSubSystem(SDL_INIT_JOYSTICK);

// [C] Initialize the SDL subsystem
if(SDL_InitSubSystem(SDL_INIT_JOYSTICK))
{
logprintf("Unable to initialize the joystick subsystem");
return false;
}

The code usually crashes in [A] (in JoystickClose) or [B] (never in
[C]), but the crashes are somewhat random. For a while it was only
crashing every 5 passes or so, but now it crashes every time through.
Debugging into the SDL code shows it crashing in all sorts of random
places inside SDL_JoystickClose() or SDL_QuitSubSystem(), even places it
should never crash, like comparing two pointers. Hence my conclusion
that it must be memory related.

I have verified that sdlJoystick is unmolested, and I can find no
obvious null pointers or similar problems in our code or the SDL code.
We use SDL for other things, such as screen rendering, without apparent
problem.

I am currently a bit stuck. I'm looking for suggestions on how to
further debug this problem. Any ideas?

Thanks much,

Chris

PS Our code is open, so I can share more if it would be helpful.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Martin Gerhardy
Guest

Quote:
I am currently a bit stuck. I'm looking for suggestions on how to
further debug this problem. Any ideas?

Thanks much,

Chris

PS Our code is open, so I can share more if it would be helpful.

Isn't there something like valgrind for windows?
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
I've spent a lot of time with the joystick API in the past couple of
weeks. I'm not immediately sure of the problem you're having and
whether it's your code or SDL's that's causing it from what you've
posted so far. Maybe I can help anyway. :)

As you probably know, SDL_NumJoysticks returns the number of
joysticks found on the system. If you run a program and it iterates
through the joysticks, you may find, for example:

0: XBox 360 controller
1: Logitech F-310 controller
2: USB NES controller

Now, let's say you disconnect the Logitech. The NES controller moves
down to index 1. If you reconnect the Logitech, it'll be index 2.
If you quit the program and restart it, the order may change
depending on what the OS tells SDL. In fact, once the joystick is
open the device index is irrelevant. You cannot even query it via
function, and you don't need to.

Internally SDL uses instance IDs. These are never renumbered, nor
are they recycled. If you unplug a joystick, its old instance ID is
dead. If you reconnect it, you get a new instance. Theoretically
you could smash the instance counter, but I don't happen to care
because I'm going to be long dead by the time you manage to do it. ;)

I consider iterating over SDL_NumJoysticks() to basically be a legacy
API, mostly because it's useful for developers to be able to spit out
the list of recognized joysticks on the system right now, perhaps
along with GameController mappings (but that's a separate API…) I'd
suggest deprecating such a construct for any other purpose, at least
within SDL's own example code. Which probably means Sam's going to
tell me to get off my something or other and do it. :)

The reason why you needn't iterate over SDL_NumJoysticks is that when
SDL first inits the joystick subsystem, it emits SDL_JOYDEVICEADDED
events for every joystick currently on the system. That means you
don't have to open and use any joysticks there at startup, then write
an event handler to also use any that get added. Write it once as an
event handler and be done.

Some notes:

1. You can open a joystick more than once. SDL refcounts joysticks.
If you SDL_JoystickOpen a device twice, the two SDL_Joystick
structures both access the same stick. If one is closed, the other
is maintained until it too is closed.

2. You can never count on the order of joysticks presented to you,
and you should not. Moreover, GUIDs are often completely arbitrary
and are not ever going to be unique to the device. Connect two PS3
controllers and you're going to have two devices with the same GUID.
For multiplayer, this means you either let the user choose the number
of players and have each user do something in sequence to tell you
which player is which, or you do it arcade style where the game
starts single player, and players 2, 3, 4 can join by pressing start
(or whatever…)

3. In an event-driven SDL application using joysticks, you won't need
the SDL_Joystick pointer for most things. You open it, query its
features, and then… listen for events from it. Events will refer to
instance IDs directly, and quitting the joystick subsystem will
destroy all SDL_Joysticks (with any pointers you had now being
invalid…)

4. SDL_JOYDEVICEREMOVED does not appear to close an opened joystick.
It's just letting you know that the given joystick for the instance
in question is gone and you can stop trying to access it. If you
kept track of multiple players' SDL_JoystickIDs from my suggestion in
#2 above, you'll know which player has dropped out of the game.

5. I can say that on SDL_JOYDEVICEREMOVED, memory is not freed. If
you have the SDL_Joystick pointer, it's not going to work. If you
have it, you theoretically could SDL_JoystickClose it, but I'm not
even 100% sure that's what you should do.

Bonus thoughts for the GameController API:

6. Although the idea is that SDL will have an extensive built-in DB
of mappings for the GameController API, it doesn't. Nonetheless,
this is a solvable problem, so if you don't need arbitrary numbers of
buttons, hats, trackballs, etc., it's worth a look.

7. The reason GameControllers are a solvable problem is that an
opened GameController is also an opened Joystick. It continues to
send Joystick events. You can use this to allow players to remap
their controls in-game. The problem here is that there's no sane way
to get SDL to tell you what the current mapping is. The only way I
know of at present is to ask for the complex config string SDL
parses internally and to parse it yourself. This is a problem I
intend to solve as soon as I'm done documenting the joystick API.


Hopefully some of that will help you identify the problem?

Joseph


On Mon, Oct 07, 2013 at 12:46:01AM +0200, Watusimoto wrote:
Quote:
Hello,

I'm having a very strange problem with joysticks in SDL2, using a
build of SDL based on code downloaded this evening. I'm working on
Windows, and built with the VC++ 10 EE project.

When I have a joystick plugged into my game, I get weird and
semi-random crashes that have all the hallmarks of a memory
corruption issue, something like a double-delete or related fault.

The overall program is fairly complex, but what we do is this, essentially:

1) Grab a joystick:

sdlJoystick = SDL_JoystickOpen(0); // only place sdlJoystick is
assigned
if(sdlJoystick == NULL) { /* error handling that is never triggered */ }

We can use this joystick for playing, and everything works fine.
Until, that is, we try to reacquire the joysticks (which we do to see
if a user has plugged a new stick in):

// [A] Close if already open
if(sdlJoystick)
{
TNLAssert(SDL_JoystickGetAttached(sdlJoystick), "Problem! --
never triggered");
SDL_JoystickClose(sdlJoystick);
sdlJoystick = NULL;
}

// [B] Will need to shutdown and init, to allow SDL_NumJoysticks
to count new joysticks
if(SDL_WasInit(SDL_INIT_JOYSTICK))
SDL_QuitSubSystem(SDL_INIT_JOYSTICK);

// [C] Initialize the SDL subsystem
if(SDL_InitSubSystem(SDL_INIT_JOYSTICK))
{
logprintf("Unable to initialize the joystick subsystem");
return false;
}

The code usually crashes in [A] (in JoystickClose) or [B] (never in
[C]), but the crashes are somewhat random. For a while it was only
crashing every 5 passes or so, but now it crashes every time through.
Debugging into the SDL code shows it crashing in all sorts of random
places inside SDL_JoystickClose() or SDL_QuitSubSystem(), even places
it should never crash, like comparing two pointers. Hence my
conclusion that it must be memory related.

I have verified that sdlJoystick is unmolested, and I can find no
obvious null pointers or similar problems in our code or the SDL
code. We use SDL for other things, such as screen rendering, without
apparent problem.

I am currently a bit stuck. I'm looking for suggestions on how to
further debug this problem. Any ideas?

Thanks much,

Chris

PS Our code is open, so I can share more if it would be helpful.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Sik


Joined: 26 Nov 2011
Posts: 905
2013/10/7, T. Joseph Carter:
Quote:
The reason why you needn't iterate over SDL_NumJoysticks is that when
SDL first inits the joystick subsystem, it emits SDL_JOYDEVICEADDED
events for every joystick currently on the system. That means you
don't have to open and use any joysticks there at startup, then write
an event handler to also use any that get added. Write it once as an
event handler and be done.

Is this expected behavior? I don't recall seeing it documented at all.
For all we know it could be a side effect and could be removed in the
future, so better have confirmation first.

Quote:
I consider iterating over SDL_NumJoysticks() to basically be a legacy
API, mostly because it's useful for developers to be able to spit out
the list of recognized joysticks on the system right now, perhaps
along with GameController mappings (but that's a separate API…) I'd
suggest deprecating such a construct for any other purpose, at least
within SDL's own example code. Which probably means Sam's going to
tell me to get off my something or other and do it. Smile

If you open every joystick then this probably isn't needed anyway,
right? (since to get the joystick names and such you'd be opening
them)
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
On Tue, Oct 08, 2013 at 12:46:53AM -0300, Sik the hedgehog wrote:
Quote:
2013/10/7, T. Joseph Carter:
Quote:
The reason why you needn't iterate over SDL_NumJoysticks is that when
SDL first inits the joystick subsystem, it emits SDL_JOYDEVICEADDED
events for every joystick currently on the system. That means you
don't have to open and use any joysticks there at startup, then write
an event handler to also use any that get added. Write it once as an
event handler and be done.

Is this expected behavior? I don't recall seeing it documented at all.
For all we know it could be a side effect and could be removed in the
future, so better have confirmation first.

It's not documented. In fact, as of SDL 2.0, the whole joystick
subsystem is basically not documented. Smile That's what I'm doing in
my copious spare time—which is even more copious this week with the
whole medical gauntlet. And on the even months, the gauntlet is even
longer due to the added tests. Guess it beats the alternative! ;)

That said, however, I'd hoped it would be true and was relieved to
find out that it was. With SDL 2.0 being final, established behavior
isn't gonna get changed without a very good reason unless it's
actually broken in some way.

I've already been talking to Sam about the potential for adding to
the API to give it some polish and make things like mapping and
remapping random joysticks to the GameController API. A lot of work
went into making the GameController API easy for programmers to use.
The problem is that it's still not easy for users to use, except via
Steam. Which is great for Valve. Not so great for the rest of us!

Basically at some point, once I've documented it (and therefore can
say that I completely understand it!), I'll be cleaning up and/or
adding tests related to joysticks and GameControllers.

The plans are:

1. Use the event API for testjoystick to handle add/remove events.

2. Spend a little more time drawing for testgamecontroller to better
visualize it. I actually made kind of a mashup of the XBox 360,
DualShock, and Wii Classic controllers (with a bit of SNES flavoring
actually) for the purpose. I did that so it'd fit in a 320 wide
iDingus screen, and because the much niftier-looking vector line
drawings of the XBox 360 controller I found don't show the triggers
because, well, they're on the back. But I don't think I'm going to
use it, actually. Instead, I think I'll use this as a base:

http://www.tattiebogle.net/index.php/ProjectRoot/Xbox360Controller/OsxDriver

(Wow that screenshot is old. Pinstripes and everything!)

Dots for sticks within a visible boundary square, arrows drawn in for
the DPad as needed, and all the buttons and triggers in the position
they actually are on the controller. AND, I don't have to draw the
thing at 320 wide if your window is bigger than that. Sold. :)

3. Add a Steam-style controller configuration test. May go into
testgamecontroller's rewrite, but … I dunno. That's gonna start
becoming a full-fledged app real quickly if I'm not careful. IMO the
purpose of the tests folder is two-fold: First to make sure some
part of SDL actually functions on a given system using known
reference code, and secondly to serve as basic developer docs in full
context of theoretically working code. Making it too fancy runs
cross-purposes to both.

But a bit of very openly licensed code included with SDL that people
are welcome to copy and modify to (re)configure GameControllers would
make everyone happy—apparently including Valve. :)

4. Since 2 and 3 above require adding some very simple ASCII text
on screen to the tests folder (pretty SDL_ttf and unicode left as an
exercise to the reader), I may take a page from Windows' own joystick
status display for testjoystick. If I do that, I have absolutely NO
idea how to visually represent trackball deltas. I don't think
testjoystick actually does at the moment, and I haven't actually got
a joystick that presents one. (If someone knows of such a thing that
connects via USB, lemme know. I may not be able to buy one, but I'd
at least try to see if I could find and borrow one for a week to make
that do something intelligent.)


Quote:
Quote:
I consider iterating over SDL_NumJoysticks() to basically be a legacy
API, mostly because it's useful for developers to be able to spit out
the list of recognized joysticks on the system right now, perhaps
along with GameController mappings (but that's a separate API…) I'd
suggest deprecating such a construct for any other purpose, at least
within SDL's own example code. Which probably means Sam's going to
tell me to get off my something or other and do it. Smile

If you open every joystick then this probably isn't needed anyway,
right? (since to get the joystick names and such you'd be opening
them)

You can actually get the name and GUID of a joystick without opening
it. The name to present to the user, and the GUID to feed SDL a
GameController mapping so SDL_IsGameController will return the
affirmative.

The other thing I think I'd like to do somewhere is stick a bit of
code that is maybe too complex for a test in SDL, but which gives the
ability to have up to 4 players using GameControllers join in one at
a time basically by pressing start. Something small and easily
understood. No idea what yet. Warlords maybe? Smile I'd considered a
4 player Mario Bros clone, but that'd get a bit crowded fast and it's
also a bit more complex than I'd want to write just to illustrate a
few simple concepts.

Joseph

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Watusimoto
Guest

On 10/08/2013 09:14 AM, T. Joseph Carter wrote:
Quote:
Spend a little more time drawing for testgamecontroller to better
visualize it.

Maybe it would be helpful, maybe not, but we created a definition file
for a bunch of joysticks that maps out what each button looks like
(color, shape, size, label), then we use that description to draw a
button map for each supported joystick.

The definition file is here:

https://code.google.com/p/bitfighter/source/browse/exe/joystick_presets.ini

If this looks interesting, stop by the #bitfighter irc channel on
freenode, and I can walk you through it and point you to some parsing
and rendering code.

Chris (watusimoto on irc)
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Watusimoto
Guest

Hi Joseph,

Thanks very much for your detailed response. It does not directly
address my problem, but it was very helpful in letting me see that we
were doing some stuff that is no longer necessary with SDL 2, and it has
let me simplify our code and help isolate the problem.

I have the crash problem much more narrowed down now, and hope to have
it pinpointed tonight. It now seems there is a negative interaction
between the SDL joystick system and something (not sure what yet) that
is going on elsewhere in our code.

Overall, I found your message very informative and useful. Hopefully
some of this info can make its way into the documentation.

Chris


On 10/07/2013 10:47 AM, T. Joseph Carter wrote:
Quote:
I've spent a lot of time with the joystick API in the past couple of
weeks. I'm not immediately sure of the problem you're having and
whether it's your code or SDL's that's causing it from what you've
posted so far. Maybe I can help anyway. :)

As you probably know, SDL_NumJoysticks returns the number of joysticks
found on the system. If you run a program and it iterates through the
joysticks, you may find, for example:

0: XBox 360 controller
1: Logitech F-310 controller
2: USB NES controller

Now, let's say you disconnect the Logitech. The NES controller moves
down to index 1. If you reconnect the Logitech, it'll be index 2. If
you quit the program and restart it, the order may change depending on
what the OS tells SDL. In fact, once the joystick is open the device
index is irrelevant. You cannot even query it via function, and you
don't need to.

Internally SDL uses instance IDs. These are never renumbered, nor are
they recycled. If you unplug a joystick, its old instance ID is
dead. If you reconnect it, you get a new instance. Theoretically you
could smash the instance counter, but I don't happen to care because
I'm going to be long dead by the time you manage to do it. ;)

I consider iterating over SDL_NumJoysticks() to basically be a legacy
API, mostly because it's useful for developers to be able to spit out
the list of recognized joysticks on the system right now, perhaps
along with GameController mappings (but that's a separate API…) I'd
suggest deprecating such a construct for any other purpose, at least
within SDL's own example code. Which probably means Sam's going to
tell me to get off my something or other and do it. :)

The reason why you needn't iterate over SDL_NumJoysticks is that when
SDL first inits the joystick subsystem, it emits SDL_JOYDEVICEADDED
events for every joystick currently on the system. That means you
don't have to open and use any joysticks there at startup, then write
an event handler to also use any that get added. Write it once as an
event handler and be done.

Some notes:

1. You can open a joystick more than once. SDL refcounts joysticks.
If you SDL_JoystickOpen a device twice, the two SDL_Joystick
structures both access the same stick. If one is closed, the other is
maintained until it too is closed.

2. You can never count on the order of joysticks presented to you, and
you should not. Moreover, GUIDs are often completely arbitrary and
are not ever going to be unique to the device. Connect two PS3
controllers and you're going to have two devices with the same GUID.
For multiplayer, this means you either let the user choose the number
of players and have each user do something in sequence to tell you
which player is which, or you do it arcade style where the game starts
single player, and players 2, 3, 4 can join by pressing start (or
whatever…)

3. In an event-driven SDL application using joysticks, you won't need
the SDL_Joystick pointer for most things. You open it, query its
features, and then… listen for events from it. Events will refer to
instance IDs directly, and quitting the joystick subsystem will
destroy all SDL_Joysticks (with any pointers you had now being invalid…)

4. SDL_JOYDEVICEREMOVED does not appear to close an opened joystick.
It's just letting you know that the given joystick for the instance in
question is gone and you can stop trying to access it. If you kept
track of multiple players' SDL_JoystickIDs from my suggestion in #2
above, you'll know which player has dropped out of the game.

5. I can say that on SDL_JOYDEVICEREMOVED, memory is not freed. If you
have the SDL_Joystick pointer, it's not going to work. If you have
it, you theoretically could SDL_JoystickClose it, but I'm not even
100% sure that's what you should do.

Bonus thoughts for the GameController API:

6. Although the idea is that SDL will have an extensive built-in DB of
mappings for the GameController API, it doesn't. Nonetheless, this is
a solvable problem, so if you don't need arbitrary numbers of buttons,
hats, trackballs, etc., it's worth a look.

7. The reason GameControllers are a solvable problem is that an opened
GameController is also an opened Joystick. It continues to send
Joystick events. You can use this to allow players to remap their
controls in-game. The problem here is that there's no sane way to get
SDL to tell you what the current mapping is. The only way I know of
at present is to ask for the complex config string SDL parses
internally and to parse it yourself. This is a problem I intend to
solve as soon as I'm done documenting the joystick API.


Hopefully some of that will help you identify the problem?

Joseph


On Mon, Oct 07, 2013 at 12:46:01AM +0200, Watusimoto wrote:
Quote:
Hello,

I'm having a very strange problem with joysticks in SDL2, using a
build of SDL based on code downloaded this evening. I'm working on
Windows, and built with the VC++ 10 EE project.

When I have a joystick plugged into my game, I get weird and
semi-random crashes that have all the hallmarks of a memory
corruption issue, something like a double-delete or related fault.

The overall program is fairly complex, but what we do is this,
essentially:

1) Grab a joystick:

sdlJoystick = SDL_JoystickOpen(0); // only place sdlJoystick is
assigned
if(sdlJoystick == NULL) { /* error handling that is never triggered
*/ }

We can use this joystick for playing, and everything works fine.
Until, that is, we try to reacquire the joysticks (which we do to see
if a user has plugged a new stick in):

// [A] Close if already open
if(sdlJoystick)
{
TNLAssert(SDL_JoystickGetAttached(sdlJoystick), "Problem! --
never triggered");
SDL_JoystickClose(sdlJoystick);
sdlJoystick = NULL;
}

// [B] Will need to shutdown and init, to allow SDL_NumJoysticks to
count new joysticks
if(SDL_WasInit(SDL_INIT_JOYSTICK))
SDL_QuitSubSystem(SDL_INIT_JOYSTICK);

// [C] Initialize the SDL subsystem
if(SDL_InitSubSystem(SDL_INIT_JOYSTICK))
{
logprintf("Unable to initialize the joystick subsystem");
return false;
}

The code usually crashes in [A] (in JoystickClose) or [B] (never in
[C]), but the crashes are somewhat random. For a while it was only
crashing every 5 passes or so, but now it crashes every time through.
Debugging into the SDL code shows it crashing in all sorts of random
places inside SDL_JoystickClose() or SDL_QuitSubSystem(), even places
it should never crash, like comparing two pointers. Hence my
conclusion that it must be memory related.

I have verified that sdlJoystick is unmolested, and I can find no
obvious null pointers or similar problems in our code or the SDL
code. We use SDL for other things, such as screen rendering, without
apparent problem.

I am currently a bit stuck. I'm looking for suggestions on how to
further debug this problem. Any ideas?

Thanks much,

Chris

PS Our code is open, so I can share more if it would be helpful.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Watusimoto
Guest

On 10/08/2013 05:46 AM, Sik the hedgehog wrote:
Quote:
Quote:
I consider iterating over SDL_NumJoysticks() to basically be a legacy
API, mostly because it's useful for developers to be able to spit out
the list of recognized joysticks on the system right now, perhaps
along with GameController mappings (but that's a separate API…) I'd
suggest deprecating such a construct for any other purpose, at least
within SDL's own example code. Which probably means Sam's going to
tell me to get off my something or other and do it. Smile

Quote:
If you open every joystick then this probably isn't needed anyway,
right? (since to get the joystick names and such you'd be opening
them)

Perosnally, I find it very useful to iterate over all plugged in sticks
without opening each -- we use SDL_NumJoysticks() along with
SDL_JoystickNameForIndex() to build a menu of available joysticks to let
the player decide which to use. We then only open the one the player
selects.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Sik


Joined: 26 Nov 2011
Posts: 905
2013/10/8, T. Joseph Carter:
Quote:
That said, however, I'd hoped it would be true and was relieved to
find out that it was. With SDL 2.0 being final, established behavior
isn't gonna get changed without a very good reason unless it's
actually broken in some way.

The problem is that if it's not documented there's no way to know if
it's intended or it should be considered undefined behavior. I doubt
that backwards compatibility will account for undefined behavior.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
As noted, there are a few bits of it that I don't fully understand
myself, but once I'm sure of those things, I am the one writing the
documentation, so it'll get in there. Smile

The biggest barrier I have to doing so is that the wiki format is
pretty terse for an individual function, and you're not supposed to
go talking about tons of unrelated functions on a given function's
page. But on some level, it becomes necessary to talk about those
details.

I'm considering the need to discuss it as justified however, since
other list regulars simply didn't know that it works that way and is
supposed to work that way. Smile

But I've got to break the info up and put it where it all belongs.
Currently I'm having trouble getting the wiki to notice I've added
some missing API functions to it. :/

Joseph


On Tue, Oct 08, 2013 at 10:37:27AM +0200, Watusimoto wrote:
Quote:
Hi Joseph,

Thanks very much for your detailed response. It does not directly
address my problem, but it was very helpful in letting me see that we
were doing some stuff that is no longer necessary with SDL 2, and it
has let me simplify our code and help isolate the problem.

I have the crash problem much more narrowed down now, and hope to
have it pinpointed tonight. It now seems there is a negative
interaction between the SDL joystick system and something (not sure
what yet) that is going on elsewhere in our code.

Overall, I found your message very informative and useful. Hopefully
some of this info can make its way into the documentation.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
On Tue, Oct 08, 2013 at 10:30:04AM +0200, Watusimoto wrote:
Quote:
Maybe it would be helpful, maybe not, but we created a definition
file for a bunch of joysticks that maps out what each button looks
like (color, shape, size, label), then we use that description to
draw a button map for each supported joystick.

The definition file is here:

https://code.google.com/p/bitfighter/source/browse/exe/joystick_presets.ini

If this looks interesting, stop by the #bitfighter irc channel on
freenode, and I can walk you through it and point you to some parsing
and rendering code.

I appreciate the offer, but I'm not sure it'll be especially useful
for something I'm throwing into the test directory. Just getting
something that represents the basic XBox 360 controller is probably
sufficient, though, since the GameController API of SDL does and is
intended to expose exactly that controller.

The fact that the DualShock and clones, the Wii classic controller,
and even the venerable SNES controller have reasonably equivalent
mapping to the XBox 360's controller is merely coincidental and
reflects that the basic SNES-derived controller has changed little,
with ironically enough Nintendo being the major exception.

Oh, sure, Sony added motion control. And Sony's buttons are pretty
much all analog now. And Microsoft kept them digital, except for the
triggers which have a longer pull (and thus more precise range) than
Sony. Not much else has changed. They're basically still souped up
SNES controllers with analog inputs and extra buttons. Smile The only
real variance from the SNES style outside of Nintendo are fighting
pads/sticks that tend to be all digital and move the two shoulder
buttons to the face, and flight sticks/yokes, which vary heavily even
from one model to the next by the same manufacturer.

The games that use flight sticks are very carefully configured and
customized on a per-user basis, so they're beyond our scope.

That common game written for the generic modern controller would
therefore expect basically a digital DPad, two analog sticks, four
face buttons, at least two (but probably four) shoulder buttons, and
at least two or three control buttons (start, etc). That sounds
remarkably like the generic Playstation clone controllers made by
just about everybody starting like 10 years ago, right?

Well sure, but if you're making something a standard, it'd be stupid
to limit it to 10 year old least common denominator technology. And
frankly, most PC gamers use Windows. On Windows, there is a game
controller standard that closely matches those minimal specs. The
XBox 360 controller. It's the standard because Microsoft says so,
and it's their OS. :)

So, SDL uses that standard. Again, since nearly everything even
close to a standard controller basically follows the SNES archetype,
less capable controllers still map to within that framework pretty
gracefully. Maybe you have no rumble motors. Maybe you have no
guide button. Maybe instead of analog triggers you have digital
L2/R2 buttons. Maybe instead of A, B, X, Y, you have X, Circle,
Square, Triangle or 2, 3, 1, 4 or even B, A, Y, X. Doesn't matter.

As long as you show the physical relationship between your standard
controls on screen, any controller with a compatible mapping will be
instantly understood by gamers and intuitively used regardless of
what they see on the screen.

I'm a great fan of the GameController API, if you can't tell. My
major reasons for getting elbow-deep into the Joystick code are:

1. Neither API was well-enough documented for me to use.

2. A bug in the test told me my GameController was not recognized as
such, even though it was, so I had to start figuring out how to map
it myself (even though I didn't need to…)

3. Making this "just work" is going to require a lot more entries to
the database OR a sane and easy GameController mapping editor. The
only one that exists is in Steam, and while Sam might be able to talk
them into sharing some graphics from their configurator, the code is
closed and wouldn't be useful anyway.

4. It needs to "just work" if users are gonna be able to use it. And
if users aren't gonna be able to use it, developers won't bother.

Besides, I needed a hobby that didn't involve keeping tabs on cancer
research and screaming at the computer screen reading news about
corrupt, petty, self-centered [CENSORED] [CENSORED] [CENSORED]… The
doctors told me I needed to watch my blood pressure. ;)

Quote:
Chris (watusimoto on irc)

It's been a long time since I opened an IRC client… I'm firmly stage
6 by now. But it might be worthwhile to pop in and say hi to people
I haven't seen in ages.

Joseph

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
On Tue, Oct 08, 2013 at 10:07:44AM -0300, Sik the hedgehog wrote:
Quote:
2013/10/8, T. Joseph Carter:
Quote:
That said, however, I'd hoped it would be true and was relieved to
find out that it was. With SDL 2.0 being final, established behavior
isn't gonna get changed without a very good reason unless it's
actually broken in some way.

The problem is that if it's not documented there's no way to know if
it's intended or it should be considered undefined behavior. I doubt
that backwards compatibility will account for undefined behavior.

Well, here's the clue:

Darwin, Linux, and Windows if using the DirectInput/XInput APIs all
do it. The only reason the Windows MMJoystick code hasn't been
pruned for bitrot reasons is that nobody has reported it to be
actually broken. (It happens to be, and the only way for me to even
realistically get a SDL that could demonstrate it would be to go set
up MingW32 for no terribly good reason!) ;)

Android is Linux.

The iPhone is Darwin, but it doesn't matter because the iPhone lacks
the ability prior to iOS 7 to actually have a joystick. As for iOS 7
and going forward, I dunno what it has, but we'd make it work the
same way most likely when writing support! The iCade doesn't count
as a joystick, because it's actually a keyboard with some clever
magic to bypass the limitations of keyboards when it comes to button
mashing.

That's all for officially supported platforms. Anything else … send
me what I need to compile and test (simulator, instructions for
vmware, whatever) and I'll make it work that way. :)

Joseph

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Mason Wheeler
Guest

It is once people start using it. Have you ever needed to implement bug-for-bug compatibility with another product, just so certain things that are being used as "features" now don't break? I have...


Mason



From: Sik the hedgehog
To: SDL Development List
Sent: Tuesday, October 8, 2013 6:07 AM
Subject: Re: [SDL] Memory corruption problem with SDL2 and joysticks


2013/10/8, T. Joseph Carter:> That said, however, I'd hoped it would be true and was relieved to> find out that it was. With SDL 2.0 being final, established behavior> isn't gonna get changed without a very good reason unless it's> actually broken in some way.The problem is that if it's not documented there's no way to know ifit's intended or it should be considered undefined behavior. I doubtthat backwards compatibility will account for undefined behavior._______________________________________________SDL mailinghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Watusimoto
Guest

Hi again,

As I wrote in an earlier message, I was able to pare the game code down
a bit to focus on the source of the crash. I pared pretty much down to
the bone, and am now left with this:

int main(int argc, char **argv)
{
SDL_Init(0);
SDL_JoystickEventState(SDL_ENABLE);
SDL_InitSubSystem(SDL_INIT_JOYSTICK);
SDL_Joystick *x = SDL_JoystickOpen(0);
SDL_JoystickClose(x);

SDL_QuitSubSystem(SDL_INIT_JOYSTICK);
exit(0);
}


The code above works fine (i.e. no crash, calm exit) when there is no
stick plugged in.
I have two sticks, one marked "hama" (the blue one), and one marked
"saitek" (the silver one). Both sticks are known to work.
When the blue stick is in, it works fine.
When the silver stick is in, this crashes, ether on the QuitSubSystem()
or on the exit.
If both are in, it also crashes, regardless of which I plug in first.
If both are in and it crashes, and I unplug the silver stick, it stops
crashing.

The stack trace is useless. But I copied it here anyway:
http://pastebin.com/KDRHGx4W

I'm not sure what to do next. Any thoughts?

Chris





On 10/7/2013 10:47 AM, T. Joseph Carter wrote:
Quote:
I've spent a lot of time with the joystick API in the past couple of
weeks. I'm not immediately sure of the problem you're having and
whether it's your code or SDL's that's causing it from what you've
posted so far. Maybe I can help anyway. :)

As you probably know, SDL_NumJoysticks returns the number of joysticks
found on the system. If you run a program and it iterates through the
joysticks, you may find, for example:

0: XBox 360 controller
1: Logitech F-310 controller
2: USB NES controller

Now, let's say you disconnect the Logitech. The NES controller moves
down to index 1. If you reconnect the Logitech, it'll be index 2. If
you quit the program and restart it, the order may change depending on
what the OS tells SDL. In fact, once the joystick is open the device
index is irrelevant. You cannot even query it via function, and you
don't need to.

Internally SDL uses instance IDs. These are never renumbered, nor are
they recycled. If you unplug a joystick, its old instance ID is
dead. If you reconnect it, you get a new instance. Theoretically you
could smash the instance counter, but I don't happen to care because
I'm going to be long dead by the time you manage to do it. ;)

I consider iterating over SDL_NumJoysticks() to basically be a legacy
API, mostly because it's useful for developers to be able to spit out
the list of recognized joysticks on the system right now, perhaps
along with GameController mappings (but that's a separate API…) I'd
suggest deprecating such a construct for any other purpose, at least
within SDL's own example code. Which probably means Sam's going to
tell me to get off my something or other and do it. :)

The reason why you needn't iterate over SDL_NumJoysticks is that when
SDL first inits the joystick subsystem, it emits SDL_JOYDEVICEADDED
events for every joystick currently on the system. That means you
don't have to open and use any joysticks there at startup, then write
an event handler to also use any that get added. Write it once as an
event handler and be done.

Some notes:

1. You can open a joystick more than once. SDL refcounts joysticks.
If you SDL_JoystickOpen a device twice, the two SDL_Joystick
structures both access the same stick. If one is closed, the other is
maintained until it too is closed.

2. You can never count on the order of joysticks presented to you, and
you should not. Moreover, GUIDs are often completely arbitrary and
are not ever going to be unique to the device. Connect two PS3
controllers and you're going to have two devices with the same GUID.
For multiplayer, this means you either let the user choose the number
of players and have each user do something in sequence to tell you
which player is which, or you do it arcade style where the game starts
single player, and players 2, 3, 4 can join by pressing start (or
whatever…)

3. In an event-driven SDL application using joysticks, you won't need
the SDL_Joystick pointer for most things. You open it, query its
features, and then… listen for events from it. Events will refer to
instance IDs directly, and quitting the joystick subsystem will
destroy all SDL_Joysticks (with any pointers you had now being invalid…)

4. SDL_JOYDEVICEREMOVED does not appear to close an opened joystick.
It's just letting you know that the given joystick for the instance in
question is gone and you can stop trying to access it. If you kept
track of multiple players' SDL_JoystickIDs from my suggestion in #2
above, you'll know which player has dropped out of the game.

5. I can say that on SDL_JOYDEVICEREMOVED, memory is not freed. If you
have the SDL_Joystick pointer, it's not going to work. If you have
it, you theoretically could SDL_JoystickClose it, but I'm not even
100% sure that's what you should do.

Bonus thoughts for the GameController API:

6. Although the idea is that SDL will have an extensive built-in DB of
mappings for the GameController API, it doesn't. Nonetheless, this is
a solvable problem, so if you don't need arbitrary numbers of buttons,
hats, trackballs, etc., it's worth a look.

7. The reason GameControllers are a solvable problem is that an opened
GameController is also an opened Joystick. It continues to send
Joystick events. You can use this to allow players to remap their
controls in-game. The problem here is that there's no sane way to get
SDL to tell you what the current mapping is. The only way I know of
at present is to ask for the complex config string SDL parses
internally and to parse it yourself. This is a problem I intend to
solve as soon as I'm done documenting the joystick API.


Hopefully some of that will help you identify the problem?

Joseph


On Mon, Oct 07, 2013 at 12:46:01AM +0200, Watusimoto wrote:
Quote:
Hello,

I'm having a very strange problem with joysticks in SDL2, using a
build of SDL based on code downloaded this evening. I'm working on
Windows, and built with the VC++ 10 EE project.

When I have a joystick plugged into my game, I get weird and
semi-random crashes that have all the hallmarks of a memory
corruption issue, something like a double-delete or related fault.

The overall program is fairly complex, but what we do is this,
essentially:

1) Grab a joystick:

sdlJoystick = SDL_JoystickOpen(0); // only place sdlJoystick is
assigned
if(sdlJoystick == NULL) { /* error handling that is never triggered
*/ }

We can use this joystick for playing, and everything works fine.
Until, that is, we try to reacquire the joysticks (which we do to see
if a user has plugged a new stick in):

// [A] Close if already open
if(sdlJoystick)
{
TNLAssert(SDL_JoystickGetAttached(sdlJoystick), "Problem! --
never triggered");
SDL_JoystickClose(sdlJoystick);
sdlJoystick = NULL;
}

// [B] Will need to shutdown and init, to allow SDL_NumJoysticks to
count new joysticks
if(SDL_WasInit(SDL_INIT_JOYSTICK))
SDL_QuitSubSystem(SDL_INIT_JOYSTICK);

// [C] Initialize the SDL subsystem
if(SDL_InitSubSystem(SDL_INIT_JOYSTICK))
{
logprintf("Unable to initialize the joystick subsystem");
return false;
}

The code usually crashes in [A] (in JoystickClose) or [B] (never in
[C]), but the crashes are somewhat random. For a while it was only
crashing every 5 passes or so, but now it crashes every time through.
Debugging into the SDL code shows it crashing in all sorts of random
places inside SDL_JoystickClose() or SDL_QuitSubSystem(), even places
it should never crash, like comparing two pointers. Hence my
conclusion that it must be memory related.

I have verified that sdlJoystick is unmolested, and I can find no
obvious null pointers or similar problems in our code or the SDL
code. We use SDL for other things, such as screen rendering, without
apparent problem.

I am currently a bit stuck. I'm looking for suggestions on how to
further debug this problem. Any ideas?

Thanks much,

Chris

PS Our code is open, so I can share more if it would be helpful.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Watusimoto
Guest

One more thing... if I remove the JoystickOpen and JoystickClose lines,
the crashes go away.

On 10/8/2013 10:31 PM, Watusimoto wrote:
Quote:
Hi again,

As I wrote in an earlier message, I was able to pare the game code
down a bit to focus on the source of the crash. I pared pretty much
down to the bone, and am now left with this:

int main(int argc, char **argv)
{
SDL_Init(0);
SDL_JoystickEventState(SDL_ENABLE);
SDL_InitSubSystem(SDL_INIT_JOYSTICK);
SDL_Joystick *x = SDL_JoystickOpen(0);
SDL_JoystickClose(x);

SDL_QuitSubSystem(SDL_INIT_JOYSTICK);
exit(0);
}


The code above works fine (i.e. no crash, calm exit) when there is no
stick plugged in.
I have two sticks, one marked "hama" (the blue one), and one marked
"saitek" (the silver one). Both sticks are known to work.
When the blue stick is in, it works fine.
When the silver stick is in, this crashes, ether on the
QuitSubSystem() or on the exit.
If both are in, it also crashes, regardless of which I plug in first.
If both are in and it crashes, and I unplug the silver stick, it stops
crashing.

The stack trace is useless. But I copied it here anyway:
http://pastebin.com/KDRHGx4W

I'm not sure what to do next. Any thoughts?

Chris





On 10/7/2013 10:47 AM, T. Joseph Carter wrote:
Quote:
I've spent a lot of time with the joystick API in the past couple of
weeks. I'm not immediately sure of the problem you're having and
whether it's your code or SDL's that's causing it from what you've
posted so far. Maybe I can help anyway. :)

As you probably know, SDL_NumJoysticks returns the number of
joysticks found on the system. If you run a program and it iterates
through the joysticks, you may find, for example:

0: XBox 360 controller
1: Logitech F-310 controller
2: USB NES controller

Now, let's say you disconnect the Logitech. The NES controller moves
down to index 1. If you reconnect the Logitech, it'll be index 2.
If you quit the program and restart it, the order may change
depending on what the OS tells SDL. In fact, once the joystick is
open the device index is irrelevant. You cannot even query it via
function, and you don't need to.

Internally SDL uses instance IDs. These are never renumbered, nor
are they recycled. If you unplug a joystick, its old instance ID is
dead. If you reconnect it, you get a new instance. Theoretically you
could smash the instance counter, but I don't happen to care because
I'm going to be long dead by the time you manage to do it. ;)

I consider iterating over SDL_NumJoysticks() to basically be a legacy
API, mostly because it's useful for developers to be able to spit out
the list of recognized joysticks on the system right now, perhaps
along with GameController mappings (but that's a separate API…) I'd
suggest deprecating such a construct for any other purpose, at least
within SDL's own example code. Which probably means Sam's going to
tell me to get off my something or other and do it. :)

The reason why you needn't iterate over SDL_NumJoysticks is that when
SDL first inits the joystick subsystem, it emits SDL_JOYDEVICEADDED
events for every joystick currently on the system. That means you
don't have to open and use any joysticks there at startup, then write
an event handler to also use any that get added. Write it once as an
event handler and be done.

Some notes:

1. You can open a joystick more than once. SDL refcounts joysticks.
If you SDL_JoystickOpen a device twice, the two SDL_Joystick
structures both access the same stick. If one is closed, the other
is maintained until it too is closed.

2. You can never count on the order of joysticks presented to you,
and you should not. Moreover, GUIDs are often completely arbitrary
and are not ever going to be unique to the device. Connect two PS3
controllers and you're going to have two devices with the same GUID.
For multiplayer, this means you either let the user choose the number
of players and have each user do something in sequence to tell you
which player is which, or you do it arcade style where the game
starts single player, and players 2, 3, 4 can join by pressing start
(or whatever…)

3. In an event-driven SDL application using joysticks, you won't need
the SDL_Joystick pointer for most things. You open it, query its
features, and then… listen for events from it. Events will refer to
instance IDs directly, and quitting the joystick subsystem will
destroy all SDL_Joysticks (with any pointers you had now being invalid…)

4. SDL_JOYDEVICEREMOVED does not appear to close an opened joystick.
It's just letting you know that the given joystick for the instance
in question is gone and you can stop trying to access it. If you
kept track of multiple players' SDL_JoystickIDs from my suggestion in
#2 above, you'll know which player has dropped out of the game.

5. I can say that on SDL_JOYDEVICEREMOVED, memory is not freed. If
you have the SDL_Joystick pointer, it's not going to work. If you
have it, you theoretically could SDL_JoystickClose it, but I'm not
even 100% sure that's what you should do.

Bonus thoughts for the GameController API:

6. Although the idea is that SDL will have an extensive built-in DB
of mappings for the GameController API, it doesn't. Nonetheless, this
is a solvable problem, so if you don't need arbitrary numbers of
buttons, hats, trackballs, etc., it's worth a look.

7. The reason GameControllers are a solvable problem is that an
opened GameController is also an opened Joystick. It continues to
send Joystick events. You can use this to allow players to remap
their controls in-game. The problem here is that there's no sane way
to get SDL to tell you what the current mapping is. The only way I
know of at present is to ask for the complex config string SDL
parses internally and to parse it yourself. This is a problem I
intend to solve as soon as I'm done documenting the joystick API.


Hopefully some of that will help you identify the problem?

Joseph


On Mon, Oct 07, 2013 at 12:46:01AM +0200, Watusimoto wrote:
Quote:
Hello,

I'm having a very strange problem with joysticks in SDL2, using a
build of SDL based on code downloaded this evening. I'm working on
Windows, and built with the VC++ 10 EE project.

When I have a joystick plugged into my game, I get weird and
semi-random crashes that have all the hallmarks of a memory
corruption issue, something like a double-delete or related fault.

The overall program is fairly complex, but what we do is this,
essentially:

1) Grab a joystick:

sdlJoystick = SDL_JoystickOpen(0); // only place sdlJoystick is
assigned
if(sdlJoystick == NULL) { /* error handling that is never
triggered */ }

We can use this joystick for playing, and everything works fine.
Until, that is, we try to reacquire the joysticks (which we do to
see if a user has plugged a new stick in):

// [A] Close if already open
if(sdlJoystick)
{
TNLAssert(SDL_JoystickGetAttached(sdlJoystick), "Problem! --
never triggered");
SDL_JoystickClose(sdlJoystick);
sdlJoystick = NULL;
}

// [B] Will need to shutdown and init, to allow SDL_NumJoysticks
to count new joysticks
if(SDL_WasInit(SDL_INIT_JOYSTICK))
SDL_QuitSubSystem(SDL_INIT_JOYSTICK);

// [C] Initialize the SDL subsystem
if(SDL_InitSubSystem(SDL_INIT_JOYSTICK))
{
logprintf("Unable to initialize the joystick subsystem");
return false;
}

The code usually crashes in [A] (in JoystickClose) or [B] (never in
[C]), but the crashes are somewhat random. For a while it was only
crashing every 5 passes or so, but now it crashes every time
through. Debugging into the SDL code shows it crashing in all sorts
of random places inside SDL_JoystickClose() or SDL_QuitSubSystem(),
even places it should never crash, like comparing two pointers.
Hence my conclusion that it must be memory related.

I have verified that sdlJoystick is unmolested, and I can find no
obvious null pointers or similar problems in our code or the SDL
code. We use SDL for other things, such as screen rendering, without
apparent problem.

I am currently a bit stuck. I'm looking for suggestions on how to
further debug this problem. Any ideas?

Thanks much,

Chris

PS Our code is open, so I can share more if it would be helpful.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
j_post
Guest

So have I.
Jeff

On Tuesday 08 October 2013 11:39:58 Mason Wheeler wrote:
Quote:
It is once people start using it. Have you ever needed to implement
bug-for-bug compatibility with another product, just so certain things
that are being used as "features" now don't break? I have...


Mason



________________________________
From: Sik the hedgehog
To: SDL Development List
Sent: Tuesday, October 8, 2013 6:07 AM
Subject: Re: [SDL] Memory corruption problem with SDL2 and joysticks

2013/10/8, T. Joseph Carter:
Quote:
That said, however, I'd hoped it would be true and was relieved to
find out that it was. With SDL 2.0 being final, established behavior
isn't gonna get changed without a very good reason unless it's
actually broken in some way.

The problem is that if it's not documented there's no way to know if
it's intended or it should be considered undefined behavior. I doubt
that backwards compatibility will account for undefined behavior.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
You guys are kinda missing the point here. Well, several points I
think.

1. There basically is no documentation of how this works, except for
what I'm writing. Your argument that this behavior should be
considered undefined will be irrelevant as soon as I actually write
the documentation and save the wiki page(s) in question. So this is
about to become documented behavior.

2. It logically cannot work any other way. Think about it.
SDL_NumJoysticks tells you how many joysticks are on the system RIGHT
NOW, whenever now happens to be. The joystick subsystem does not and
cannot reasonably be expected to know what joysticks you know about
already. So when it adds a new joystick to the system, it sends an
event, automatically.

3. When the joystick subsystem initializes, it performs a scan for
joysticks on your system. For each one it finds, it _adds_ them.
And what does SDL do when a joystick is added under 2.0? It emits
SDL_JOYDEVICEADDED. The fact that this happens at init time is
irrelevant to the function. The whole point to SDL_JOYDEVICEADDED is
to tell your application that a joystick that wasn't there before has
been added to the system.

4. If it worked any other way, you'd introduce unexpected behavior.
Think about it. SDL_NumJoysticks reports the CURRENT number of
joysticks on the system. That number can change between init and
whenever you query it for iteration. Moreover, it can change in the
middle of your iterative loop! Under SDL 1.2, unplugging a joystick
was a no-no and would cause it to stop working. Plugging one in
didn't help because any joysticks that were added after init were not
seen. But XBox 360 controllers (and presumably PS3 controllers, but
I haven't got one to test) both appear and disappear all the time.

5. The only supported target that doesn't already do it this way is
the Windows MMJoystick code. And it's a bug that it doesn't work,
because the code fails to recognize when joystick devices are
connected and disconnected at all. It can, but it doesn't, because
SDL's windows developers all use the DirectInput/XInput driver, and
for good reason. Ten years worth of obscure joystick-related bugs
are directly attributable to that stinking heap of a Windows API, and
the only reason I haven't actually backported the DInput/XInput
driver to SDL 1.2 is that Sam told me not to bother at this point.

I'm actually kinda lobbying to have the MMJoystick driver yanked from
SDL at this point. But I'll patch the event-related bug if someone
wants to compile and test the patch. Because of the many bugs you'll
encounter trying to use MMJoystick, the lack of events is the single
one that isn't in Windows itself. :)

The major objection to pulling it will be that MingW32 cannot compile
the DirectInput driver with its standard toolchain and headers. I
note that is true, but MingW-W64 can, and MingW32 appears to be
obsoleting itself in a grand and arrogant display of Not Invented
Here Syndrome… (MingW-W64's DirectX headers come from WINE and thus
could be included in MingW32, but aren't.)

Joseph


On Tue, Oct 08, 2013 at 11:39:58AM -0700, Mason Wheeler wrote:
Quote:
It is once people start using it.  Have you ever needed to implement bug-for-bug compatibility with another product, just so certain things that are being used as "features" now don't break?  I have...


Mason



________________________________
From: Sik the hedgehog
To: SDL Development List
Sent: Tuesday, October 8, 2013 6:07 AM
Subject: Re: [SDL] Memory corruption problem with SDL2 and joysticks


2013/10/8, T. Joseph Carter:
Quote:
That said, however, I'd hoped it would be true and was relieved to
find out that it was.  With SDL 2.0 being final, established behavior
isn't gonna get changed without a very good reason unless it's
actually broken in some way.

The problem is that if it's not documented there's no way to know if
it's intended or it should be considered undefined behavior. I doubt
that backwards compatibility will account for undefined behavior.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Quote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
On Tue, Oct 08, 2013 at 10:31:26PM +0200, Watusimoto wrote:
Quote:
Hi again,

As I wrote in an earlier message, I was able to pare the game code
down a bit to focus on the source of the crash. I pared pretty much
down to the bone, and am now left with this:

int main(int argc, char **argv)
{
SDL_Init(0);
SDL_JoystickEventState(SDL_ENABLE);
SDL_InitSubSystem(SDL_INIT_JOYSTICK);
SDL_Joystick *x = SDL_JoystickOpen(0);
SDL_JoystickClose(x);

SDL_QuitSubSystem(SDL_INIT_JOYSTICK);
exit(0);
}

Okay, if THAT is crashing for any reason other than possibly
SDL_JoystickClose failing to check for NULL pointer (and it does),
the bug is not yours. Either SDL is broken, or Windows is.

I have suspicions.


Quote:
The code above works fine (i.e. no crash, calm exit) when there is no
stick plugged in.
I have two sticks, one marked "hama" (the blue one), and one marked
"saitek" (the silver one). Both sticks are known to work.
When the blue stick is in, it works fine.
When the silver stick is in, this crashes, ether on the
QuitSubSystem() or on the exit.

Interesting! Not on the close. But either on the QuitSubsystem or
on the exit? Mind sticking something in there to tease that out? A
simple delay ought to do it. If it crashes before the delay is
finished 100% of the time, we know it's the QuitSubsystem.


Quote:
If both are in, it also crashes, regardless of which I plug in first.
If both are in and it crashes, and I unplug the silver stick, it
stops crashing.

The stack trace is useless. But I copied it here anyway:
http://pastebin.com/KDRHGx4W

I'm not sure what to do next. Any thoughts?

There's some issue with your Saitek stick.

Yes, I no really want to know if you're using the DirectInput or
MMJoystick APIs in SDL. Does your config.h define SDL_JOYSTICK_WINMM
or SDL_JOYSTICK_DINPUT? I continue to lobby for the removal of the
former. Smile

Knowing which SDL is building with for you will help track down the
cause of the problem, which clearly seems to be somewhere below the
platform independent code.

Joseph

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Sik


Joined: 26 Nov 2011
Posts: 905
2013/10/9, T. Joseph Carter:
Quote:
I'm actually kinda lobbying to have the MMJoystick driver yanked from
SDL at this point. But I'll patch the event-related bug if someone
wants to compile and test the patch. Because of the many bugs you'll
encounter trying to use MMJoystick, the lack of events is the single
one that isn't in Windows itself. Smile

Given what was discussed not long ago that modern drivers for that API
are completely broken (I even wouldn't be surprised if it's just some
generic wrapper on top of the drivers for the other APIs), it probably
should be removed because it's completely broken and there's nothing
SDL can do about it.

Quote:
The major objection to pulling it will be that MingW32 cannot compile
the DirectInput driver with its standard toolchain and headers. I
note that is true, but MingW-W64 can, and MingW32 appears to be
obsoleting itself in a grand and arrogant display of Not Invented
Here Syndrome… (MingW-W64's DirectX headers come from WINE and thus
could be included in MingW32, but aren't.)

I was under the impression development on MinGW was stopped long ago
(it has been stuck on the same feature set for *years*) and MinGW-w64
was a fork from people who wanted to keep it up to date. Granted, I'm
just guessing, so I'm probably wrong.

At this point I would say MinGW in itself should be considered a bug
and become deprecated, and from now on assume MinGW-w64 will be always
used in its place.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Watusimoto
Guest

I've been probing this crash thing a little further, and wanted to add a
few new details.

First of all, I can reproduce the crash when someone else builds on a
different machine; therefore I conclude the problem is not related to
any particularities in my build system.

Second, the joystick that causes the crash is the Saitek P480 Rumble Pad
(or at least Windows recognizes it as such). I have two of these
sticks, and both cause the problem. Therefore I conclude that it is not
a particular joystick that is the problem, though the problem could be
related to the model.

Third, I tried running the testjoystick code that comes with SDL, and it
exhibits the same problem. This removes any doubt that it is related to
Bitfighter.

So... that's the state of things.

Chris



On 10/8/2013 10:37 PM, Watusimoto wrote:
Quote:
One more thing... if I remove the JoystickOpen and JoystickClose
lines, the crashes go away.

On 10/8/2013 10:31 PM, Watusimoto wrote:
Quote:
Hi again,

As I wrote in an earlier message, I was able to pare the game code
down a bit to focus on the source of the crash. I pared pretty much
down to the bone, and am now left with this:

int main(int argc, char **argv)
{
SDL_Init(0);
SDL_JoystickEventState(SDL_ENABLE);
SDL_InitSubSystem(SDL_INIT_JOYSTICK);
SDL_Joystick *x = SDL_JoystickOpen(0);
SDL_JoystickClose(x);

SDL_QuitSubSystem(SDL_INIT_JOYSTICK);
exit(0);
}


The code above works fine (i.e. no crash, calm exit) when there is no
stick plugged in.
I have two sticks, one marked "hama" (the blue one), and one marked
"saitek" (the silver one). Both sticks are known to work.
When the blue stick is in, it works fine.
When the silver stick is in, this crashes, ether on the
QuitSubSystem() or on the exit.
If both are in, it also crashes, regardless of which I plug in first.
If both are in and it crashes, and I unplug the silver stick, it
stops crashing.

The stack trace is useless. But I copied it here anyway:
http://pastebin.com/KDRHGx4W

I'm not sure what to do next. Any thoughts?

Chris





On 10/7/2013 10:47 AM, T. Joseph Carter wrote:
Quote:
I've spent a lot of time with the joystick API in the past couple of
weeks. I'm not immediately sure of the problem you're having and
whether it's your code or SDL's that's causing it from what you've
posted so far. Maybe I can help anyway. :)

As you probably know, SDL_NumJoysticks returns the number of
joysticks found on the system. If you run a program and it iterates
through the joysticks, you may find, for example:

0: XBox 360 controller
1: Logitech F-310 controller
2: USB NES controller

Now, let's say you disconnect the Logitech. The NES controller
moves down to index 1. If you reconnect the Logitech, it'll be
index 2. If you quit the program and restart it, the order may
change depending on what the OS tells SDL. In fact, once the
joystick is open the device index is irrelevant. You cannot even
query it via function, and you don't need to.

Internally SDL uses instance IDs. These are never renumbered, nor
are they recycled. If you unplug a joystick, its old instance ID is
dead. If you reconnect it, you get a new instance. Theoretically
you could smash the instance counter, but I don't happen to care
because I'm going to be long dead by the time you manage to do it. ;)

I consider iterating over SDL_NumJoysticks() to basically be a
legacy API, mostly because it's useful for developers to be able to
spit out the list of recognized joysticks on the system right now,
perhaps along with GameController mappings (but that's a separate
API…) I'd suggest deprecating such a construct for any other
purpose, at least within SDL's own example code. Which probably
means Sam's going to tell me to get off my something or other and do
it. :)

The reason why you needn't iterate over SDL_NumJoysticks is that
when SDL first inits the joystick subsystem, it emits
SDL_JOYDEVICEADDED events for every joystick currently on the
system. That means you don't have to open and use any joysticks
there at startup, then write an event handler to also use any that
get added. Write it once as an event handler and be done.

Some notes:

1. You can open a joystick more than once. SDL refcounts
joysticks. If you SDL_JoystickOpen a device twice, the two
SDL_Joystick structures both access the same stick. If one is
closed, the other is maintained until it too is closed.

2. You can never count on the order of joysticks presented to you,
and you should not. Moreover, GUIDs are often completely arbitrary
and are not ever going to be unique to the device. Connect two PS3
controllers and you're going to have two devices with the same
GUID. For multiplayer, this means you either let the user choose
the number of players and have each user do something in sequence to
tell you which player is which, or you do it arcade style where the
game starts single player, and players 2, 3, 4 can join by pressing
start (or whatever…)

3. In an event-driven SDL application using joysticks, you won't
need the SDL_Joystick pointer for most things. You open it, query
its features, and then… listen for events from it. Events will refer
to instance IDs directly, and quitting the joystick subsystem will
destroy all SDL_Joysticks (with any pointers you had now being
invalid…)

4. SDL_JOYDEVICEREMOVED does not appear to close an opened
joystick. It's just letting you know that the given joystick for
the instance in question is gone and you can stop trying to access
it. If you kept track of multiple players' SDL_JoystickIDs from my
suggestion in #2 above, you'll know which player has dropped out of
the game.

5. I can say that on SDL_JOYDEVICEREMOVED, memory is not freed. If
you have the SDL_Joystick pointer, it's not going to work. If you
have it, you theoretically could SDL_JoystickClose it, but I'm not
even 100% sure that's what you should do.

Bonus thoughts for the GameController API:

6. Although the idea is that SDL will have an extensive built-in DB
of mappings for the GameController API, it doesn't. Nonetheless,
this is a solvable problem, so if you don't need arbitrary numbers
of buttons, hats, trackballs, etc., it's worth a look.

7. The reason GameControllers are a solvable problem is that an
opened GameController is also an opened Joystick. It continues to
send Joystick events. You can use this to allow players to remap
their controls in-game. The problem here is that there's no sane
way to get SDL to tell you what the current mapping is. The only way
I know of at present is to ask for the complex config string SDL
parses internally and to parse it yourself. This is a problem I
intend to solve as soon as I'm done documenting the joystick API.


Hopefully some of that will help you identify the problem?

Joseph


On Mon, Oct 07, 2013 at 12:46:01AM +0200, Watusimoto wrote:
Quote:
Hello,

I'm having a very strange problem with joysticks in SDL2, using a
build of SDL based on code downloaded this evening. I'm working on
Windows, and built with the VC++ 10 EE project.

When I have a joystick plugged into my game, I get weird and
semi-random crashes that have all the hallmarks of a memory
corruption issue, something like a double-delete or related fault.

The overall program is fairly complex, but what we do is this,
essentially:

1) Grab a joystick:

sdlJoystick = SDL_JoystickOpen(0); // only place sdlJoystick
is assigned
if(sdlJoystick == NULL) { /* error handling that is never
triggered */ }

We can use this joystick for playing, and everything works fine.
Until, that is, we try to reacquire the joysticks (which we do to
see if a user has plugged a new stick in):

// [A] Close if already open
if(sdlJoystick)
{
TNLAssert(SDL_JoystickGetAttached(sdlJoystick), "Problem! --
never triggered");
SDL_JoystickClose(sdlJoystick);
sdlJoystick = NULL;
}

// [B] Will need to shutdown and init, to allow SDL_NumJoysticks
to count new joysticks
if(SDL_WasInit(SDL_INIT_JOYSTICK))
SDL_QuitSubSystem(SDL_INIT_JOYSTICK);

// [C] Initialize the SDL subsystem
if(SDL_InitSubSystem(SDL_INIT_JOYSTICK))
{
logprintf("Unable to initialize the joystick subsystem");
return false;
}

The code usually crashes in [A] (in JoystickClose) or [B] (never in
[C]), but the crashes are somewhat random. For a while it was only
crashing every 5 passes or so, but now it crashes every time
through. Debugging into the SDL code shows it crashing in all sorts
of random places inside SDL_JoystickClose() or SDL_QuitSubSystem(),
even places it should never crash, like comparing two pointers.
Hence my conclusion that it must be memory related.

I have verified that sdlJoystick is unmolested, and I can find no
obvious null pointers or similar problems in our code or the SDL
code. We use SDL for other things, such as screen rendering,
without apparent problem.

I am currently a bit stuck. I'm looking for suggestions on how to
further debug this problem. Any ideas?

Thanks much,

Chris

PS Our code is open, so I can share more if it would be helpful.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
I think we also concluded that you ARE using the DirectInput driver.
Which means that nuking MMJoystick, which would give me great
pleasure otherwise, will not solve the problem. :)

Joseph


On Thu, Oct 10, 2013 at 01:07:25AM +0200, Watusimoto wrote:
Quote:
I've been probing this crash thing a little further, and wanted to
add a few new details.

First of all, I can reproduce the crash when someone else builds on a
different machine; therefore I conclude the problem is not related to
any particularities in my build system.

Second, the joystick that causes the crash is the Saitek P480 Rumble
Pad (or at least Windows recognizes it as such). I have two of these
sticks, and both cause the problem. Therefore I conclude that it is
not a particular joystick that is the problem, though the problem
could be related to the model.

Third, I tried running the testjoystick code that comes with SDL, and
it exhibits the same problem. This removes any doubt that it is
related to Bitfighter.

So... that's the state of things.

Chris



On 10/8/2013 10:37 PM, Watusimoto wrote:
Quote:
One more thing... if I remove the JoystickOpen and JoystickClose
lines, the crashes go away.

On 10/8/2013 10:31 PM, Watusimoto wrote:
Quote:
Hi again,

As I wrote in an earlier message, I was able to pare the game code
down a bit to focus on the source of the crash. I pared pretty much
down to the bone, and am now left with this:

int main(int argc, char **argv)
{
SDL_Init(0);
SDL_JoystickEventState(SDL_ENABLE);
SDL_InitSubSystem(SDL_INIT_JOYSTICK);
SDL_Joystick *x = SDL_JoystickOpen(0);
SDL_JoystickClose(x);

SDL_QuitSubSystem(SDL_INIT_JOYSTICK);
exit(0);
}


The code above works fine (i.e. no crash, calm exit) when there is no
stick plugged in.
I have two sticks, one marked "hama" (the blue one), and one marked
"saitek" (the silver one). Both sticks are known to work.
When the blue stick is in, it works fine.
When the silver stick is in, this crashes, ether on the
QuitSubSystem() or on the exit.
If both are in, it also crashes, regardless of which I plug in first.
If both are in and it crashes, and I unplug the silver stick, it
stops crashing.

The stack trace is useless. But I copied it here anyway:
http://pastebin.com/KDRHGx4W

I'm not sure what to do next. Any thoughts?

Chris





On 10/7/2013 10:47 AM, T. Joseph Carter wrote:
Quote:
I've spent a lot of time with the joystick API in the past couple of
weeks. I'm not immediately sure of the problem you're having and
whether it's your code or SDL's that's causing it from what you've
posted so far. Maybe I can help anyway. :)

As you probably know, SDL_NumJoysticks returns the number of
joysticks found on the system. If you run a program and it iterates
through the joysticks, you may find, for example:

0: XBox 360 controller
1: Logitech F-310 controller
2: USB NES controller

Now, let's say you disconnect the Logitech. The NES controller
moves down to index 1. If you reconnect the Logitech, it'll be
index 2. If you quit the program and restart it, the order may
change depending on what the OS tells SDL. In fact, once the
joystick is open the device index is irrelevant. You cannot even
query it via function, and you don't need to.

Internally SDL uses instance IDs. These are never renumbered, nor
are they recycled. If you unplug a joystick, its old instance ID is
dead. If you reconnect it, you get a new instance. Theoretically
you could smash the instance counter, but I don't happen to care
because I'm going to be long dead by the time you manage to do it. ;)

I consider iterating over SDL_NumJoysticks() to basically be a
legacy API, mostly because it's useful for developers to be able to
spit out the list of recognized joysticks on the system right now,
perhaps along with GameController mappings (but that's a separate
API…) I'd suggest deprecating such a construct for any other
purpose, at least within SDL's own example code. Which probably
means Sam's going to tell me to get off my something or other and do
it. :)

The reason why you needn't iterate over SDL_NumJoysticks is that
when SDL first inits the joystick subsystem, it emits
SDL_JOYDEVICEADDED events for every joystick currently on the
system. That means you don't have to open and use any joysticks
there at startup, then write an event handler to also use any that
get added. Write it once as an event handler and be done.

Some notes:

1. You can open a joystick more than once. SDL refcounts
joysticks. If you SDL_JoystickOpen a device twice, the two
SDL_Joystick structures both access the same stick. If one is
closed, the other is maintained until it too is closed.

2. You can never count on the order of joysticks presented to you,
and you should not. Moreover, GUIDs are often completely arbitrary
and are not ever going to be unique to the device. Connect two PS3
controllers and you're going to have two devices with the same
GUID. For multiplayer, this means you either let the user choose
the number of players and have each user do something in sequence to
tell you which player is which, or you do it arcade style where the
game starts single player, and players 2, 3, 4 can join by pressing
start (or whatever…)

3. In an event-driven SDL application using joysticks, you won't
need the SDL_Joystick pointer for most things. You open it, query
its features, and then… listen for events from it. Events will refer
to instance IDs directly, and quitting the joystick subsystem will
destroy all SDL_Joysticks (with any pointers you had now being
invalid…)

4. SDL_JOYDEVICEREMOVED does not appear to close an opened
joystick. It's just letting you know that the given joystick for
the instance in question is gone and you can stop trying to access
it. If you kept track of multiple players' SDL_JoystickIDs from my
suggestion in #2 above, you'll know which player has dropped out of
the game.

5. I can say that on SDL_JOYDEVICEREMOVED, memory is not freed. If
you have the SDL_Joystick pointer, it's not going to work. If you
have it, you theoretically could SDL_JoystickClose it, but I'm not
even 100% sure that's what you should do.

Bonus thoughts for the GameController API:

6. Although the idea is that SDL will have an extensive built-in DB
of mappings for the GameController API, it doesn't. Nonetheless,
this is a solvable problem, so if you don't need arbitrary numbers
of buttons, hats, trackballs, etc., it's worth a look.

7. The reason GameControllers are a solvable problem is that an
opened GameController is also an opened Joystick. It continues to
send Joystick events. You can use this to allow players to remap
their controls in-game. The problem here is that there's no sane
way to get SDL to tell you what the current mapping is. The only way
I know of at present is to ask for the complex config string SDL
parses internally and to parse it yourself. This is a problem I
intend to solve as soon as I'm done documenting the joystick API.


Hopefully some of that will help you identify the problem?

Joseph


On Mon, Oct 07, 2013 at 12:46:01AM +0200, Watusimoto wrote:
Quote:
Hello,

I'm having a very strange problem with joysticks in SDL2, using a
build of SDL based on code downloaded this evening. I'm working on
Windows, and built with the VC++ 10 EE project.

When I have a joystick plugged into my game, I get weird and
semi-random crashes that have all the hallmarks of a memory
corruption issue, something like a double-delete or related fault.

The overall program is fairly complex, but what we do is this,
essentially:

1) Grab a joystick:

sdlJoystick = SDL_JoystickOpen(0); // only place sdlJoystick
is assigned
if(sdlJoystick == NULL) { /* error handling that is never
triggered */ }

We can use this joystick for playing, and everything works fine.
Until, that is, we try to reacquire the joysticks (which we do to
see if a user has plugged a new stick in):

// [A] Close if already open
if(sdlJoystick)
{
TNLAssert(SDL_JoystickGetAttached(sdlJoystick), "Problem! --
never triggered");
SDL_JoystickClose(sdlJoystick);
sdlJoystick = NULL;
}

// [B] Will need to shutdown and init, to allow SDL_NumJoysticks
to count new joysticks
if(SDL_WasInit(SDL_INIT_JOYSTICK))
SDL_QuitSubSystem(SDL_INIT_JOYSTICK);

// [C] Initialize the SDL subsystem
if(SDL_InitSubSystem(SDL_INIT_JOYSTICK))
{
logprintf("Unable to initialize the joystick subsystem");
return false;
}

The code usually crashes in [A] (in JoystickClose) or [B] (never in
[C]), but the crashes are somewhat random. For a while it was only
crashing every 5 passes or so, but now it crashes every time
through. Debugging into the SDL code shows it crashing in all sorts
of random places inside SDL_JoystickClose() or SDL_QuitSubSystem(),
even places it should never crash, like comparing two pointers.
Hence my conclusion that it must be memory related.

I have verified that sdlJoystick is unmolested, and I can find no
obvious null pointers or similar problems in our code or the SDL
code. We use SDL for other things, such as screen rendering,
without apparent problem.

I am currently a bit stuck. I'm looking for suggestions on how to
further debug this problem. Any ideas?

Thanks much,

Chris

PS Our code is open, so I can share more if it would be helpful.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Vittorio Giovara
Guest

On Wed, Oct 9, 2013 at 2:25 PM, Sik the hedgehog
wrote:
Quote:
Quote:
The major objection to pulling it will be that MingW32 cannot compile
the DirectInput driver with its standard toolchain and headers. I
note that is true, but MingW-W64 can, and MingW32 appears to be
obsoleting itself in a grand and arrogant display of Not Invented
Here Syndrome… (MingW-W64's DirectX headers come from WINE and thus
could be included in MingW32, but aren't.)

I was under the impression development on MinGW was stopped long ago
(it has been stuck on the same feature set for *years*) and MinGW-w64
was a fork from people who wanted to keep it up to date. Granted, I'm
just guessing, so I'm probably wrong.

At this point I would say MinGW in itself should be considered a bug
and become deprecated, and from now on assume MinGW-w64 will be always
used in its place.


You are correct as far as I know.
There is literally no roadblock for a MMJoystick implementation.
Vittorio
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
D B
Guest

Yes, we are using DINPUT and not WINMM

D

On Wed, Oct 9, 2013 at 5:10 PM, T. Joseph Carter
wrote:
Quote:
I think we also concluded that you ARE using the DirectInput driver. Which
means that nuking MMJoystick, which would give me great pleasure otherwise,
will not solve the problem. :)

Joseph



On Thu, Oct 10, 2013 at 01:07:25AM +0200, Watusimoto wrote:
Quote:

I've been probing this crash thing a little further, and wanted to add a
few new details.

First of all, I can reproduce the crash when someone else builds on a
different machine; therefore I conclude the problem is not related to any
particularities in my build system.

Second, the joystick that causes the crash is the Saitek P480 Rumble Pad
(or at least Windows recognizes it as such). I have two of these sticks,
and both cause the problem. Therefore I conclude that it is not a
particular joystick that is the problem, though the problem could be related
to the model.

Third, I tried running the testjoystick code that comes with SDL, and it
exhibits the same problem. This removes any doubt that it is related to
Bitfighter.

So... that's the state of things.

Chris



On 10/8/2013 10:37 PM, Watusimoto wrote:
Quote:

One more thing... if I remove the JoystickOpen and JoystickClose
lines, the crashes go away.

On 10/8/2013 10:31 PM, Watusimoto wrote:
Quote:

Hi again,

As I wrote in an earlier message, I was able to pare the game code
down a bit to focus on the source of the crash. I pared pretty much
down to the bone, and am now left with this:

int main(int argc, char **argv)
{
SDL_Init(0);
SDL_JoystickEventState(SDL_ENABLE);
SDL_InitSubSystem(SDL_INIT_JOYSTICK);
SDL_Joystick *x = SDL_JoystickOpen(0);
SDL_JoystickClose(x);

SDL_QuitSubSystem(SDL_INIT_JOYSTICK);
exit(0);
}


The code above works fine (i.e. no crash, calm exit) when there is no
stick plugged in.
I have two sticks, one marked "hama" (the blue one), and one marked
"saitek" (the silver one). Both sticks are known to work.
When the blue stick is in, it works fine.
When the silver stick is in, this crashes, ether on the
QuitSubSystem() or on the exit.
If both are in, it also crashes, regardless of which I plug in first.
If both are in and it crashes, and I unplug the silver stick, it
stops crashing.

The stack trace is useless. But I copied it here anyway:
http://pastebin.com/KDRHGx4W

I'm not sure what to do next. Any thoughts?

Chris





On 10/7/2013 10:47 AM, T. Joseph Carter wrote:
Quote:

I've spent a lot of time with the joystick API in the past couple of
weeks. I'm not immediately sure of the problem you're having and
whether it's your code or SDL's that's causing it from what you've
posted so far. Maybe I can help anyway. :)

As you probably know, SDL_NumJoysticks returns the number of
joysticks found on the system. If you run a program and it iterates
through the joysticks, you may find, for example:

0: XBox 360 controller
1: Logitech F-310 controller
2: USB NES controller

Now, let's say you disconnect the Logitech. The NES controller
moves down to index 1. If you reconnect the Logitech, it'll be
index 2. If you quit the program and restart it, the order may
change depending on what the OS tells SDL. In fact, once the
joystick is open the device index is irrelevant. You cannot even
query it via function, and you don't need to.

Internally SDL uses instance IDs. These are never renumbered, nor
are they recycled. If you unplug a joystick, its old instance ID is
dead. If you reconnect it, you get a new instance. Theoretically
you could smash the instance counter, but I don't happen to care
because I'm going to be long dead by the time you manage to do it. ;)

I consider iterating over SDL_NumJoysticks() to basically be a
legacy API, mostly because it's useful for developers to be able to
spit out the list of recognized joysticks on the system right now,
perhaps along with GameController mappings (but that's a separate
API…) I'd suggest deprecating such a construct for any other
purpose, at least within SDL's own example code. Which probably
means Sam's going to tell me to get off my something or other and do
it. :)

The reason why you needn't iterate over SDL_NumJoysticks is that
when SDL first inits the joystick subsystem, it emits
SDL_JOYDEVICEADDED events for every joystick currently on the
system. That means you don't have to open and use any joysticks
there at startup, then write an event handler to also use any that
get added. Write it once as an event handler and be done.

Some notes:

1. You can open a joystick more than once. SDL refcounts
joysticks. If you SDL_JoystickOpen a device twice, the two
SDL_Joystick structures both access the same stick. If one is
closed, the other is maintained until it too is closed.

2. You can never count on the order of joysticks presented to you,
and you should not. Moreover, GUIDs are often completely arbitrary
and are not ever going to be unique to the device. Connect two PS3
controllers and you're going to have two devices with the same
GUID. For multiplayer, this means you either let the user choose
the number of players and have each user do something in sequence to
tell you which player is which, or you do it arcade style where the
game starts single player, and players 2, 3, 4 can join by pressing
start (or whatever…)

3. In an event-driven SDL application using joysticks, you won't
need the SDL_Joystick pointer for most things. You open it, query
its features, and then… listen for events from it. Events will refer
to instance IDs directly, and quitting the joystick subsystem will
destroy all SDL_Joysticks (with any pointers you had now being
invalid…)

4. SDL_JOYDEVICEREMOVED does not appear to close an opened
joystick. It's just letting you know that the given joystick for
the instance in question is gone and you can stop trying to access
it. If you kept track of multiple players' SDL_JoystickIDs from my
suggestion in #2 above, you'll know which player has dropped out of
the game.

5. I can say that on SDL_JOYDEVICEREMOVED, memory is not freed. If
you have the SDL_Joystick pointer, it's not going to work. If you
have it, you theoretically could SDL_JoystickClose it, but I'm not
even 100% sure that's what you should do.

Bonus thoughts for the GameController API:

6. Although the idea is that SDL will have an extensive built-in DB
of mappings for the GameController API, it doesn't. Nonetheless,
this is a solvable problem, so if you don't need arbitrary numbers
of buttons, hats, trackballs, etc., it's worth a look.

7. The reason GameControllers are a solvable problem is that an
opened GameController is also an opened Joystick. It continues to
send Joystick events. You can use this to allow players to remap
their controls in-game. The problem here is that there's no sane
way to get SDL to tell you what the current mapping is. The only way
I know of at present is to ask for the complex config string SDL
parses internally and to parse it yourself. This is a problem I
intend to solve as soon as I'm done documenting the joystick API.


Hopefully some of that will help you identify the problem?

Joseph


On Mon, Oct 07, 2013 at 12:46:01AM +0200, Watusimoto wrote:
Quote:

Hello,

I'm having a very strange problem with joysticks in SDL2, using a
build of SDL based on code downloaded this evening. I'm working on
Windows, and built with the VC++ 10 EE project.

When I have a joystick plugged into my game, I get weird and
semi-random crashes that have all the hallmarks of a memory
corruption issue, something like a double-delete or related fault.

The overall program is fairly complex, but what we do is this,
essentially:

1) Grab a joystick:

sdlJoystick = SDL_JoystickOpen(0); // only place sdlJoystick
is assigned
if(sdlJoystick == NULL) { /* error handling that is never
triggered */ }

We can use this joystick for playing, and everything works fine.
Until, that is, we try to reacquire the joysticks (which we do to
see if a user has plugged a new stick in):

// [A] Close if already open
if(sdlJoystick)
{
TNLAssert(SDL_JoystickGetAttached(sdlJoystick), "Problem! --
never triggered");
SDL_JoystickClose(sdlJoystick);
sdlJoystick = NULL;
}

// [B] Will need to shutdown and init, to allow SDL_NumJoysticks
to count new joysticks
if(SDL_WasInit(SDL_INIT_JOYSTICK))
SDL_QuitSubSystem(SDL_INIT_JOYSTICK);

// [C] Initialize the SDL subsystem
if(SDL_InitSubSystem(SDL_INIT_JOYSTICK))
{
logprintf("Unable to initialize the joystick subsystem");
return false;
}

The code usually crashes in [A] (in JoystickClose) or [B] (never in
[C]), but the crashes are somewhat random. For a while it was only
crashing every 5 passes or so, but now it crashes every time
through. Debugging into the SDL code shows it crashing in all sorts
of random places inside SDL_JoystickClose() or SDL_QuitSubSystem(),
even places it should never crash, like comparing two pointers.
Hence my conclusion that it must be memory related.

I have verified that sdlJoystick is unmolested, and I can find no
obvious null pointers or similar problems in our code or the SDL
code. We use SDL for other things, such as screen rendering,
without apparent problem.

I am currently a bit stuck. I'm looking for suggestions on how to
further debug this problem. Any ideas?

Thanks much,

Chris

PS Our code is open, so I can share more if it would be helpful.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Memory corruption problem with SDL2 and joysticks
Ryan C. Gordon
Guest

Quote:
Second, the joystick that causes the crash is the Saitek P480 Rumble Pad
(or at least Windows recognizes it as such). I have two of these
sticks, and both cause the problem. Therefore I conclude that it is not
a particular joystick that is the problem, though the problem could be
related to the model.

My guess is these are XInput compatible and the others aren't (or vice
versa), and either the XInput or DirectInput code paths are buggy. I'm
trying to track this issue down still.

If you add this to the very start of the program...

SDL_SetHint("SDL_XINPUT_ENABLED", "0");

...does the crash vanish?

Also: this is with the latest in Mercurial, and not the 2.0.0 release,
right? The XInput code got a big overhaul right after 2.0.0 shipped.

--ryan.



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org