dev-libs/libusbx-1.0.13 was added to portage and it breaks games-util/xboxdrv. It crashes either at startup or at exit. Unfortunately, libusbx-1.0.12 was removed from portage. As a workaround, I had to add it back and modify virtual/libusb to allow for 1.0.12.
Created attachment 324596 [details] Crash message.
Created attachment 324598 [details] emerge --info
1.0.13 was a mistake what should have been prerelease of 1.1 1.0.14 is now in portage and reverts bunch of stuff that belongs to 1.1 series which involves raising the shared library's versioning one notch if 1.0.14 fixes your issue, then this problem will be likely happen again with 1.1 series later...
Issue is there with 1.0.14 too.
ok, run a `revdep-rebuild --library libusb-1.0.so.0` and report back if this fixes things (rebuilding the system against the new library) just want to make sure headers match what is installed globally to out that possibility
This resulted in rebuilding the following: [ebuild R ] dev-libs/libusb-compat-0.1.4 [ebuild R ] sys-apps/usbutils-006 [ebuild R ] app-emulation/emul-linux-x86-medialibs-20120520 [ebuild R ] games-util/xboxdrv-0.8.4 [ebuild R ] sys-power/upower-0.9.18 [ebuild R ] net-print/cups-1.6.1 (I manually removed www-client/chromium using "-- --exclude chromium", as that takes too long to build and it doesn't have an effect on xboxdrv.) The problem is still there after rebuilding all of the above.
(In reply to comment #6) > The problem is still there after rebuilding all of the above. I'm libusb upstream. Nikos, do I understand correctly that you do not have the issue with libusbx-1.0.12? Could I also ask you to also try libusb-1.0.9 and see if it is present there? Rather than looking into the details of the problem Samuli seems to be shooting suggestions from the hip. This issue has nothing whatsoever to do with the API modification that libusbx introduced in their 1.0.13 release and then undid in 1.0.14 a few days later when packages could not build anymore.
(In reply to comment #7) > (In reply to comment #6) > > The problem is still there after rebuilding all of the above. > > I'm libusb upstream. > > Nikos, do I understand correctly that you do not have the issue with > libusbx-1.0.12? > > Could I also ask you to also try libusb-1.0.9 and see if it is present there? How does that help? It doesn't. We should be looking at the diff between 1.0.12 and 1.0.14 for the cause. > > Rather than looking into the details of the problem Samuli seems to be It's normal to require users to use latest and report bugs only from latest... > shooting suggestions from the hip. This issue has nothing whatsoever to do > with the API modification that libusbx introduced in their 1.0.13 release > and then undid in 1.0.14 a few days later when packages could not build > anymore. Nod, now that it's been tested we can go forward with the bug...
(In reply to comment #8) > > Could I also ask you to also try libusb-1.0.9 and see if it is present there? > > How does that help? It doesn't. More data points are better, they help us (both libusb and libusbx) upstream to find and fix the problem. Do you follow both libusb.git and libusbx.git history closely? Using libusb-1.0.9 may also be a good solution for the user if the problem is not present there, since the ebuild is in the tree. (Don't be tricked by the version numbers Nikos, libusbx have made several releases, but not with as much content as one might expect.) > We should be looking at the diff between 1.0.12 and 1.0.14 for the cause. If libusbx-1.0.12 works then sure, but the libusb-1.0.9 data point is no less valuable. I'm glad that you want to get more involved in the project and dive into the code! > > Rather than looking into the details of the problem Samuli seems to be > > It's normal to require users to use latest and report bugs only from > latest... Not when the difference between what the user first tried (libusbx-1.0.13) and latest (libusbx-1.0.14) is a single commit, which removes one letter from the public header file. In that case, requiring users to use latest is unneccessarily wasting their time IMO. (I'm sure you noticed that it's a runtime crash and not a build error.)
(In reply to comment #7) > Nikos, do I understand correctly that you do not have the issue with > libusbx-1.0.12? Yes. Only 1.0.13 and 1.0.14 trigger the problem. I bisected the problem to this commit: d2e8b37a68b06b8d75e9bd947b8a90d570a77778 is the first bad commit commit d2e8b37a68b06b8d75e9bd947b8a90d570a77778 Author: Orin Eman <orin.eman@gmail.com> Date: Fri Aug 3 14:21:45 2012 +0100 Core: NULL list pointers on deletion * This aims at highlighting unwanted behaviours on list operations, and facilitate early detection of potential bugs. * This also requires a fix in threads_windows.c * See http://sourceforge.net/mailarchive/message.php?msg_id=29626351 :040000 040000 2d02340baa58096f17973a4a9c9257a0b14b62f7 7235b08e8f3042e7272037feeedb4bf61b091a04 M libusb > Could I also ask you to also try libusb-1.0.9 and see if it is present there? Just tested. That one works fine. In case it helps, I got a backtrace with gdb: (glib version is 2.32.4-r1) #0 0x00007f7ee19b8234 in __GI___poll (fds=0x17621b0, nfds=5, timeout=10) at ../sysdeps/unix/sysv/linux/poll.c:83 #1 0x00007f7ee2dc3204 in g_main_context_poll (n_fds=5, fds=0x17621b0, timeout=10, context=0x175d500, priority=<optimized out>) at gmain.c:3440 #2 g_main_context_iterate (context=0x175d500, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3141 #3 0x00007f7ee2dc3652 in g_main_loop_run (loop=0x1718220) at gmain.c:3340 #4 0x0000000000421c95 in XboxdrvMain::run (this=0x7fff52b640d0) at src/xboxdrv_main.cpp:216 #5 0x0000000000409f6f in Xboxdrv::run_main (this=this@entry=0x7fff52b6440f, opts=...) at src/xboxdrv.cpp:200 #6 0x0000000000408778 in Xboxdrv::main (this=0x7fff52b6440f, argc=2, argv=0x7fff52b64508) at src/xboxdrv.cpp:396 #7 0x0000000000408694 in main (argc=2, argv=0x7fff52b64508) at src/main/main.cpp:24
Upstream (xboxdrv) has fixed the issue in their Git repo. Bug report: https://github.com/Grumbel/xboxdrv/issues/28 Patch: https://github.com/Grumbel/xboxdrv/commit/27cdd9c6a994f3059b8ae683adb711169341ffa5.patch I applied the patch (per /etc/portage/patches) and it fixes the issue here.
+ 09 Jan 2013; Sergey Popov <pinkbyte@gentoo.org> +xboxdrv-0.8.4-r1.ebuild, + +files/xboxdrv-0.8.4-libusbx-1.0.13-fix.patch: + Revision bump: EAPI 5, use base eclass, add compatibility fix for libusbx, + wrt bug #435832 Please, test
Oops, sorry for the delay. Somehow I missed the update of this bug. This works fine now. No more crashes.
