jstest SEGFAULTs with usb joystick

crash backtrace

I can replicate this for AMD64 with a different joystick (Saitek X52), although the package was not in the repositories (I locally compiled from https://launchpad.net/distros/ubuntu/dapper/+source/joystick/20051019-1ubuntu1).

In addition, there seems to be a kernel issue with the MP-8866 Joypad, addressed by http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/2.6/2.6.16-rc5/wisegroup-mp-8866-dual-usb-joypad.patch. This is part of mainline 2.6.16, so it will automatically be applied when the kernel next syncs with upstream.

As a workaround, the js_demo program shipped with flightgear provides a fair amount of information about joysticks (including tracking interaction with axes and buttons) and input-events from the input-utils package will provide an event dump while using the joystick.

thanks for the js_demo tip, I'll check that out.

It would be great if that patch could be backported to current Dapper kernel, it looks pretty trivial, low risky to me.

Nothing in here points to glibc so far. Most of the time when glibc is at the end of the stack trace, it's because bad data has been handed in. You might try ltrace to see what glibc was called with. As always, the trick is getting a decent reduced testcase.

I also beleive that the final Dapper kernel has been uploaded already, so you're unlikely to see that fixed until Edgy opens up.

I'm fairly sure the error is in the jscal source. There is no validation checking of the parameters returned from the kernel before posting them in a printf() call. Given that the current version appears to be mostly packaging changes from a 7 month old copy of the linux kernel headers, I suspect something is missing in the call interface.

using ltrace, the output is

puts(")"Joystick (WiseGroup.,Ltd MP-8866 Dual USB Joypad) has 12 axes (X, X, X, X, X, X, X, X, X, X, X, X)
) = 2
printf("and %d buttons (", 24) = 16
printf("%s%s", "", "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"... <unfinished ...>
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

that output is generated on jscal.c print_info() function,
line 186 and onwards.

I can confirm this bug,

---------
$ jstest /dev/input/js0
Driver version is 2.1.0.
Joystick (Saitek Saitek X52 Flight Control System) has 11 axes (X, X, X, X, X, X, X, X, X, X, X)
Segmentation fault
---------

By the way, has someone a working config-file for the X52-Joystick for FlightGear? fgjs does not work because it is skipping all axis.

The problem with flightgear is actually a problem with all games that use the freeglut input library. The required patch follows:

--- src/freeglut_joystick.c 2005-05-04 21:53:48.000000000 +0900
+++ src/freeglut_joystick.c.X52 2006-05-25 06:24:14.000000000 +0900
@@ -45,7 +45,7 @@
 /* XXX It might be better to poll the operating system for the numbers of buttons and
  * XXX axes and then dynamically allocate the arrays.
  */
-#define _JS_MAX_BUTTONS 32
+#define _JS_MAX_BUTTONS 48

 #if TARGET_HOST_MACINTOSH
 # define _JS_MAX_AXES 9

    I'll submit a bug and debdiff this weekend (unless someone beats me to it), but that doesn't address the issue with jstest.

Never mind. Freeglut uses an int (32-bit) to hold the values of all the buttons. I don't want to cause performance issues on 32-bit hardware just to support the Saitek X52. Everything but the rear wheel on the throttle should work fine.

The problem appears to be that Dapper uses the event interface for USB joysticks and that jstest uses the older interface. Attached is a debdiff that enables the evtest binary which prints useful information for joystick testing.

I don't think that's the reason: at least, it doesn't seem to be for me. My joystick is /dev/input/js0, I want to use that, not some event* name like evtest forces.

jstest works fine, with the exception that it segfaults when it tries to print out the "names" of the buttons.

The ioctls that fill in axmap and btnmap fill in all-zeroes. For axmap, that results in a proclamation that all the axes are named "X". For btnmap, that /segfaults/, because the values are expected to be in the range [BTN_MISC, KEY_MAX], and no error-checking is done.

Here is a patch on jstest.c that fixed the segfault for me.

Note that, AFAICT, jstest is smart enough to autodetect which interface it uses, so I don't think that's the problem.

I just wanted to throw in my two cents worth, and see if i could offer some help. I am not familiar with programming, but its amazing what some agrivation can accomplish, hehe. I managed to use gdb to print some debugging info on the segmentation fault that I am experiencing, its output included in the attached file. the gamepad that I am trying to use is reported as the following to lshw:

        *-usb:1
             description: USB Controller
             product: VT82xxxxx UHCI USB 1.1 Controller
             vendor: VIA Technologies, Inc.
             physical id: 10.1
             bus info: pci@00:10.1
             version: 81
             width: 32 bits
             clock: 33MHz
             capabilities: uhci bus_master cap_list
             configuration: driver=uhci_hcd
             resources: ioport:ac00-ac1f irq:185
           *-usbhost
                product: UHCI Host Controller
                vendor: Linux 2.6.15-26-386 uhci_hcd
                physical id: 1
                bus info: usb@2
                logical name: usb2
                version: 2.06
                capabilities: usb-1.10
                configuration: driver=hub maxpower=0mA slots=2 speed=12.0MB/s
              *-usb
                   description: Human interface device
                   product: Super Smartjoy 2
                   vendor: Smartjoy Family
                   physical id: 2
                   bus info: usb@2:2
                   version: 2.10
                   capabilities: usb-1.10
                   configuration: driver=usbhid maxpower=100mA speed=1.5MB/s

Rejecting the kenrel portion of this, since I'm sure it isn't related to the problem.

Unrelated to glibc as well, rejecting that task

Source patch accepted and uploaded. It'll be in 1ubuntu2.

Just had a support question from a Dapper user experiencing this bug. It'd be nice to have this in SRU.

Attached is debdiff for dapper-proposed.

Switching back to In Progress pending SRU for Dapper

As a rule, SRUs are reserved for critical, high-impact bugs; for this reason, I believe it is very unlikely to be accepted for SRU.

However, the version that has been released for edgy work as-is on Dapper; simply downloading that package and installing it via "dpkg -i <package.deb>" should work fine. I'd recommend suggesting that to any who would like the fix on their Dapper systems.

https://launchpad.net/ubuntu/+source/joystick/20051019-1ubuntu2
(Follow the links to get a downloadable .deb for your architecture.)

If you decide that you agree with me wrt suitability as an SRU, please change the status back to "Fix Released". In the future, I think it'd be preferable to submit a separate bug for SRU requests, so that it can be tracked separately/have a separate status.

Please don't assign bugs to ubuntu-universe-sponsors, only subscribe.
Assigning to jdong.

Is anyone working on this bug, or does anyone still encounter the problem? There are several patches above, and all are quite old. I'm entirely uncertain what, if anything, must be done to enable USB support for jstest.

The fix has already been released in Feisty; this bug was reopened for an SRU.

I'm reclosing the bug, so that it won't confuse people any longer. John Dong, please use a separate bug to track the SRU, and don't forget to subscribe ubuntu-universe-sponsors (but don't assign). Thanks.

> The fix has already been released in Feisty

Edgy, rather.