I'll need to open up the code and take a little deeper look when I have time, but it seems odd that this issue is just now being reported. Do you know if this is a regression (possibly related to SDL2 changes), or has this been around for some time?

We might want to throw a Python error in this case.

In BA forum they said the script was working in 2.72. The script only fails because of the sigsev. I'm not sure if I can attach the test file because it is not mine. Because just some of the functions checks for that null pointer, and the sensor Evaluate method checks that precondition too, my guess is that those functions have been modified but not tested without a joystick.

Throwing a python error would be definitely more consistent but doing so would break backward compatibility (if we assume it somehow worked before). I'll try to check what revision or patch changed that code - if any.

Well, SCA_Joystick.cpp might be the source of the problems. Still, because SCA_Joystick::getInstance has NULL among its valid return values, the null check should be left in place, preferably with some log warning, otherwise the user code in the sensor will sigsegv. It's a patch, in the truest sense.

Hold on, it worked in 2.72 (checked) and it should work in 2.73 even with no npe checks, that's just a workaround. I'll find out what's going on...

Ok, here's the thing. I had the crash because my build was set to WITH_SDL off. When that happens:

84: SCA_Joystick *SCA_Joystick::GetInstance( short int joyindex )
85: {
86: #ifndef WITH_SDL
87: return NULL;
88: #else /* WITH_SDL */

I've got the null that crashes blender. Btw, git tells that it has been added in 2008 because of sdl going crazy on OSX, but a few functions have been added a year later - probably when sdl started working again or users stopped using OSX - didn't check for null but worked anyway. That explains why the check is there for some functions but not for others and why things worked the same.

It is still a fix, for the previous considerations (GetInstance can return null). But it is unlikely to be the cause of the issue at hand, because blender is built with SDL activated and the user that experienced the crash had an issue that was only equal in the result (that *joy being null in SCA_JoystickSensor), but has to have a different cause.

I asked OTO (the user) if he sees any message in the console before the crash but, waiting for the answer, my guess is that the answer is no. If so, and SCA_Joystick is guilty, then the only(?) way it can spit out nulls without printing messages is if it does the same thing it did to me when SDL was disabled (lucky me) but with SDL enabled, and that is this if:

88: #else /* WITH_SDL */
89: if (!SDL_CHECK(SDL_InitSubSystem)) {
90: return NULL;
91: }

If SDL_InitSubSystem is zero, then there might be something going on with the library or the linking process or the libraries on the user. I'll try to find a way to confirm it.