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
|
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
|
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:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Memory corruption problem with SDL2 and joysticks |
Sik
|
2013/10/7, T. Joseph Carter:
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.
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
|
On Tue, Oct 08, 2013 at 12:46:53AM -0300, Sik the hedgehog wrote:
It's not documented. In fact, as of SDL 2.0, the whole joystick subsystem is basically not documented. 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.)
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? 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:
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:
_______________________________________________ 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:
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
|
2013/10/8, T. Joseph Carter:
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
|
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. 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. 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:
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Memory corruption problem with SDL2 and joysticks |
Joseph Carter
|
On Tue, Oct 08, 2013 at 10:30:04AM +0200, Watusimoto wrote:
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. 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. ;)
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
|
On Tue, Oct 08, 2013 at 10:07:44AM -0300, Sik the hedgehog wrote:
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:
_______________________________________________ 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:
_______________________________________________ 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:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Memory corruption problem with SDL2 and joysticks |
Joseph Carter
|
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:
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||
|
Memory corruption problem with SDL2 and joysticks |
Joseph Carter
|
On Tue, Oct 08, 2013 at 10:31:26PM +0200, Watusimoto wrote:
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.
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.
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. 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
|
2013/10/9, T. Joseph Carter:
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.
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:
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||
|
Memory corruption problem with SDL2 and joysticks |
Joseph Carter
|
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:
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:
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:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||||
|
Memory corruption problem with SDL2 and joysticks |
Ryan C. Gordon
Guest
|
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 |
|||||||||||||
|