madfuload crashes with 'segmentation fault' on amd64

dmesg shows this error message on my laptop.

[ 2891.049921] madfuload[11218]: segfault at 53ef1727 ip 00007f4e53e3a690 sp 00007fff5c3438b8 error 4 in libc-2.8.90.so[7f4e53db8000+169000]

I have been facing this problem for a while; it used to work fine with Dapper.

There is an open bug against madfuload for this very problem, and mr_batschner seems to have identified where the issue is with a gdb trace:
http://sourceforge.net/tracker2/?func=detail&aid=1905613&group_id=87777&atid=584353

There is a patch attached to the bug, but from the bug details, may not be a complete fix. If someone with C skills can take a look at it, it would be fantastic.

The segmentation fault is caused by the missing usbfs.
While this isn't fixed you can try the following workaround.

Create an entry in /etc/fstab like this:
none /proc/bus/usb usbfs devgid=46,devmode=664 0 0

This is another bug related to bug #156085

Actually, I take that back. It does look like there is a /proc/bus/usb issue, but that is separate from the segfault.

exactly. /proc/bus/usb issue exists on both platforms and easily fixable, but crash happens only on amd64

Well, the /proc/bus/usb issue simply appears to be that you gave that path on the command-line no? What happens when you give a /dev/bus/usb command-line instead?

I've uploaded a fix to the madfuload package udev rules

The attached patch is very incorrect, I can't see what it's trying to do at all - va_start takes the name of a function argument, and the patch breaks that

Scott, this bug is not about the /dev/bus/usb issue, it is about segfault on amd64.

I know, my first comment was simply addressing the fact that there was another problem.

The second comment still stands - the attached patch will not work

1) it seems that the seg fault is caused by strerror(errno).
After replacing strerror(errno) with a default text, no segmentation faults happens anymore.

2) thanks to Strider -> Bug #102631 I replaced in the madfuload.rules file
ACTION=="add", SUBSYSTEM=="usb", DEVPATH=="/*.0", ENV{PRODUCT}=="763/2806/*", RUN+="/usr/sbin/madfuload -l -3 -f /usr/share/usb/maudio/ma006100.bin -D $root/$name"
with
ACTION=="add", SUBSYSTEM=="usb", ENV{PRODUCT}=="763/2806/*", RUN+="/usr/sbin/madfuload -l -3 -f /usr/share/usb/maudio/ma006100.bin -D $env{DEVNAME}"

Then, madfuload works flawlessly with my Transit on amd64.

remark to my comment above:

To be more precise: In the output subroutines "fatal", "warning" and "logmsg" in madfuload.c the pointer(?) strerror(errno) is converted into a string via %s,
e.g. in line 289: fatal("cannot claim interface %d: (%d) %s", interface, errno, strerror(errno)).

I think, this is where the segmentation fault happens. if strerror(errno) is converted to an integer %d instead, then no seg fault occurs and obviously madfuload returns an integer as result of strerror(errno).

Pls forgive my descriptions, I am no programmer ;-)

I can confirm this bug

madfuload[3839]: segfault at b4432dc2 ip 00007f10b437ac40 sp 00007fffbc889aa8 error 4 in libc-2.9.so[7f10b42fa000+168000]

This particular bug is caused by the lack of the correct header definitions in the C file. The implicit declarations are breaking things on a 64-bit architecture.

The attached patch will at least get the 'failed to load error' into the syslog!

Scott - are you happy to package this patch or would you like me to repackage?

This patch works fine for me, thanks

The debdiff below fixes this fault, the device loading problems and generally tidies up the package so that it conforms to standards.

For those that can't wait, the package for Karmic is available on my PPA.

https://launchpad.net/~neil-aldur/+archive/ppa