usb_find_devices() crashed with SIGSEGV in free()

StacktraceTop:*__GI___libc_free (mem=0x1) at malloc.c:3687
usb_destroy_configuration (dev=0x66dbe0)
usb_free_dev (dev=0x1) at ../usb.c:293
usb_find_devices () at ../usb.c:121
dkp_device_csr_init (csr=0x66a560)

Crash happens in libusb, reassigning.

Could it be duplicate to this?: https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bug/551940

Anyway, libusb-0.1 is not supported for a long time now so there is no chance to get a patch from there.

According to libusb developers libusb-compat-0.1 (version 1.0.3) provides backwards compatibility for programs that were linked against libusb-0.1

Is there a chance that this will ever make it to lucid?

Might be worth replacing libusb-0.1 with libusb-compat since anecdotal evidence (https://bugs.launchpad.net/ubuntu/+source/upower/+bug/526895/comments/8) would appear to suggest it fixes this issue.

Could someone instuct how to replave libusb-compat with libusb-0.1
Should I just built the libusb-compat package and name it to libusb-0.1 or should they both be installed?

There seems to be a bunch of duplicates floating around Launchpad. Can someone give me a way to reproduce this bug so we can make sure the other bugs are really duplicates of this one? Thanks in advance!

The ones I manually marked as duplicates all have the same stack-trace which is pretty much a dead give-away. Unfortunately there seems no good way to reproduce it - Fedora also have the exact same issue - https://bugzilla.redhat.com/show_bug.cgi?id=580570 - which is apparently being looked at by the main upower developer (Richard Hughes at redhat) since this seems to trigger the crash in libusb

I attached a debdiff that brings the latest fix from Richard Hughes to the current upower package in Lucid. If you want to test it, you may apply it or wait until the updated package is built and available in my PPA.

Wow, that was quick. The updated packages are available from ppa:philippe-gauthier/ppa

@Philippe - thanks for that, will test later tonight when I get the chance - in the meantime I notice your debdiff says this fixes this bug - unfortunately this bug is against libusb-0.1 which isn't fixed, it just works around upower triggering this bug. Regardless, thanks again for generating the diff - also I think you'll need to look at updating build depends in debian/control so that we build against libusb-1.0-dev not libusb-dev

@Alex : The packaging of the patch is quite ugly because I struggled with the autoconf files, and I was happy enough when the source package finally built. If the fix works, I will try to re-package it better, even if it means a little bit more testing... Also, the debian/control file seems to have libusb-1.0-0-dev as a build dependency ; is there something I missed?

So there is absolutely no chance that libusb-0.1 will be fixed or replaced with libusb-compat which also means that there is absolutely no support for years now for libusb-0.1 neither from native developers nor canonical?

By the way this bug is only the top of the iceberg caused by deprecated libusb-0.1

This happens intermittently on my Macbook Pro 5.5, so I debugged into this for a while. And found there is an incorrect free due to the memory not being zero-ed during allocation. The attached patch tries to fix this issue (at least it worked on my side). And I've yet built the libusb packages at: http://people.canonical.com/~ycmiao/lp427805/libusb-0.1-4_0.1.12-14~lp427805_amd64.deb. Please test and report back.

Can you build a package for i386?
I tried to do it myself, but "debian/rules binary" fails with errors.

Try remove config.guess and config.sub before issueing an 'debian/rules binary', ugly but should work.

Thanks Eric, I agree this definitely looks like the potential culprit for this crash. Am just rebuilding libusb now with your patch so I can test it and will report back with results. Thanks again for your effort in debugging this.

Also I've attached a patch which I found on the redhat bugzilla (can't seem to find the original bug report atm) which also addresses a possible logic error in libusb - Eric can you review and perhaps incorporate with the existing patch you've just posted? Cheers?field.comment=Also I've attached a patch which I found on the redhat bugzilla (can't seem to find the original bug report atm) which also addresses a possible logic error in libusb - Eric can you review and perhaps incorporate with the existing patch you've just posted? Cheers

@Märt, finally built with my PPA and uploaded both amd64 and i386 version of the package to http://people.canonical.com/~ycmiao/lp427805. Please check and report.

@Alex, yeah the patch looks OK. I'll see if we can get this into lucid-update. Thanks.

I now installed Your new version. Since the bug does not appear every time, I cannot report immediately that it works. I will test for a week and let You know if the bug has reappeared or not.

@Märt, yeah that's something nasty. I tried plug and un-plug my power several times but didn't managed to get this reproduced. But once it happens, it seems to last forever. So a possible way to verify is to use the original libusb package first, and til this issue happens, install the updated one, and try start upower on command line to see if it crashes. gnome-power-manager seems to be staying at an incorrect state once upowerd crashes, so you may want to kill and start gnome-power-manager manually to bring it back to a right state.

@Eric: your package worked for me, on a Macbook Pro 5,5 (amd64). I had the bug, installed it then suspended and it worked (didn't work before). I think it would be good to get this patch to the official repos.

@Eric: same for me on a MacBook Pro 5,5 running lucid. I can now suspend and resume without having libusb segfault in the process. Thanks!

Seems to have fixed the issue on my MB 5,1 running Lucid as well.

-Barry Flanagan

On 9 June 2010 22:42, Olivier Grisel <email address hidden> wrote:
> @Eric: same for me on a MacBook Pro 5,5 running lucid. I can now suspend
> and resume without having libusb segfault in the process. Thanks!
>
> --
> usb_find_devices() crashed with SIGSEGV in free()
> https://bugs.launchpad.net/bugs/427805
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in libusb: New
> Status in “libusb” package in Ubuntu: In Progress
>
> Bug description:
> Binary package hint: devicekit-power
>
> rolando@defiant:~$ lsb_release -rd
> Description:    Ubuntu karmic (development branch)
> Release:        9.10
>
> Hi, I only turn on my computer and then i saw the bug
>
> ProblemType: Crash
> Architecture: amd64
> Date: Thu Sep 10 04:39:51 2009
> DistroRelease: Ubuntu 9.10
> ExecutablePath: /usr/lib/devicekit-power/devkit-power-daemon
> NonfreeKernelModules: wl nvidia
> Package: devicekit-power 010-0ubuntu1
> ProcCmdline: /usr/lib/devicekit-power/devkit-power-daemon
> ProcEnviron:
>
> ProcVersionSignature: Ubuntu 2.6.31-10.30-generic
> SegvAnalysis:
>  Segfault happened at: 0x7f8ac7ddf629 <free+25>:        mov    -0x8(%rdi),%rax
>  PC (0x7f8ac7ddf629) ok
>  source "-0x8(%rdi)" (0x-0000007) not located in a known VMA region (needed readable region)!
>  destination "%rax" ok
> SegvReason: reading NULL VMA
> Signal: 11
> SourcePackage: devicekit-power
> StacktraceTop:
>  free () from /lib/libc.so.6
>  usb_destroy_configuration ()
>  usb_free_dev () from /lib/libusb-0.1.so.4
>  usb_find_devices () from /lib/libusb-0.1.so.4
>  ?? ()
> Title: devkit-power-daemon crashed with SIGSEGV in free()
> Uname: Linux 2.6.31-10-generic x86_64
> UserGroups:
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/libusb/+bug/427805/+subscribe
>

This bug was fixed in the package libusb - 2:0.1.12-15ubuntu1

---------------
libusb (2:0.1.12-15ubuntu1) maverick; urgency=low

  * Add 07_altsetting_alloc.patch: Fix crash due to uninitialized memory.
    Thanks to Eric Miao for debugging this and the patch! (LP: #427805)
 -- Martin Pitt <email address hidden> Tue, 15 Jun 2010 09:19:06 +0200

Accepted libusb into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Thanks Martin, I can confirm this seems to fix the problem for me.

This bug was fixed in the package libusb - 2:0.1.12-14ubuntu0.1

---------------
libusb (2:0.1.12-14ubuntu0.1) lucid-proposed; urgency=low

  * Add 07_altsetting_alloc.patch: Fix crash due to uninitialized memory.
    Thanks to Eric Miao for debugging this and the patch! (LP: #427805)
 -- Martin Pitt <email address hidden> Tue, 15 Jun 2010 09:26:07 +0200

This update seems to be causing some problems for people using HPLIP and HP Laserjet printers. After installing libusb-0.1-4 version 2:0.1.12-14ubuntu0.1 yesterday, I could no longer print on my HP Laserjet 3030 printer and hp-toolbox would report a "Device communication error 5012". Some googling lead me to http://newyork.ubuntuforums.org/showthread.php?t=1518226, so I downgraded, rebooted and now everything seems to be working fine again. Thus, at least two of us seem to be experiencing this problem.

I am running Lucid amd64.

I'm sorry I don't have any additional information, I just thought that it should be reported somewhere and this thread seemed like the right place to do it.

Please let me know if you need anything else.

The above-mentioned problem was also reported to Ubuntu as bug #595650.

Sorry to bother You ... from bug #595650 ...

I noticed that update manager propose libusb 0.1.12-14ubuntu0.1 as "recommended update" (sorry for my English ... I'm translating from Italian), but I have experienced that this libusb upgrade is faulty, at least for HP printers. Therefore I suppose it could be better to stop announcing it as a "recommended update". As long as people will install it, more and more HP printers stop working (I suppose).

Ciao
CM

The patch applied is actually very wrong. And it breaks for example gnokii.
If you look at the code you find this:

interface->altsetting = realloc(interface->altsetting, sizeof(struct usb_interface_descriptor) * (interface->num_altsetting + 1));

Which means that the structure is reallocated to add new altsetting. If you then zero the whole altsetting you zero all previous altsetting. What about zeroing just allocated space? Please see the attached patch (untested).

With libusb - 2:0.1.12-14ubuntu0.1 and the corresponding -dev package gnokii doesn't find the FBUS endpoint.

I'm attaching the output of lsusb -vvv for a Nokia phone for 2:0.1.12-14 (working) and for 2:0.1.12-14ubuntu0.1 (not working).

This is the output of lsusb -vvv -d 0421: when gnokii is not working.

The patch in comment #33 that only zeroes the last altsetting works for me.

Reopening, since this caused regressions and needs a different patch.

Indeed the previous patch would overwrite previous altsettings, sorry that I didn't spot this. When I reviewed this original SRU, I just looked at the realloc()/memset() sequence, which seems fine at the first sight. realloc() by no way guarantees you that the reallocated pointer is still the same as the original one, so you would have to copy the previous contents if they are different. But the code does not do that and blindly assumes that the pointer remains constant.

However, Pawel's patch avoids the regression in bug 595650 and does not scribble over the previously written altsettings, so I'll sponsor this into lucid. Thanks a lot!

Updated libusb uploaded to lucid-proposed, awaiting SRU team review.

This bug was fixed in the package libusb - 2:0.1.12-15ubuntu2

---------------
libusb (2:0.1.12-15ubuntu2) maverick; urgency=low

  * 07_altsetting_alloc.patch: Update patch to only clear the current
    altsetting record in the loop, not overwrite previously written ones.
    Thanks to Pawel Kot! (LP: #427805, #595650)
 -- Martin Pitt <email address hidden> Mon, 12 Jul 2010 08:20:34 +0200

As for realloc(). It indeed does not guarantee that it will point out to the old chunk of memory. However it does guarantee that it will copy the relevant part of the memory. Reading man realloc:
 The contents will be unchanged to the minimum of the old and new sizes;
So that should be just enough.

Accepted libusb into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I should be wrong: up to date I'm not able to download the proposed package. Please, see here below ... what should I change to download and test the new patched package?

~$ tail -1 /etc/apt/sources.list
deb http://archive.ubuntu.com/ubuntu/ lucid-proposed restricted main multiverse universe

~$ sudo aptitude install libusb/lucid-proposed
Lettura elenco dei pacchetti... Fatto
Generazione albero delle dipendenze
Lettura informazioni sullo stato... Fatto
Lettura delle informazioni sullo stato esteso
Inizializzazione dello stato dei pacchetti... Fatto
Impossibile trovare il pacchetto «libusb». Ad ogni modo, i seguenti
pacchetti hanno un nome che contiene «libusb»:
  libusbip0 libusb-1.0-0-udeb-dbgsym libusb-1.0-0-dbgsym
  libusb-0.1-4-dbgsym libusbprog0 libusbip0-dbgsym libusb-ruby1.9.1
  libusb-1.0-0-dev libusb-ruby1.8-dbgsym libusb++-0.1-4c2
  libusbmuxd1-dbgsym libusb-ruby1.8 libusb-ruby libusb-dev libusbprog-dev
  libusbmuxd-dev libusb-ruby1.9.1-dbgsym libusb-0.1-4
  libusb++-0.1-4c2-dbgsym libusbmuxd1 libusbprog0-dbgsym libusb++-dev
  libusbip-dev libusb-1.0-0 libusbmuxd1-dbg
Nessun pacchetto verrà installato, aggiornato o rimosso.
0 pacchetti aggiornati, 0 installati, 0 da rimuovere e 54 non aggiornati.
È necessario prelevare 0B di archivi. Dopo l'estrazione, verranno occupati 0B.

Grazie. Ciao.
CM

Ops! Forget my previous comment #43 ... I installed PROPOSED libusb-0.1-4 and it runs well: IT WORKS FOR ME.

Ciao
Thanks.
CM

This bug was fixed in the package libusb - 2:0.1.12-14ubuntu0.2

---------------
libusb (2:0.1.12-14ubuntu0.2) lucid-proposed; urgency=low

  * 07_altsetting_alloc.patch: Update patch to only clear the current
    altsetting record in the loop, not overwrite previously written ones.
    Thanks to Pawel Kot! (LP: #427805, #595650)
 -- Martin Pitt <email address hidden> Mon, 12 Jul 2010 08:26:54 +0200