Bug 432129

Created attachment 243393 [details]
first launch crash spewage

Created attachment 243394 [details]
import crash spewage

Note: all I did was click the Import button.  No actual importing was involved.

Oops, actually found in Beta 2.

I'm unable to replicate this.

Mark was able to trigger this bug using "gphoto2 -a":
 
libusb couldn't open USB device /dev/bus/usb/001/001: Permission denied.
libusb requires write access to USB device nodes.
Segmentation fault

Not directly f-spot related, and there's nothing we can do to catch this inside f-spot (unfortunately, crashes in native code results in vm crashes)

It should not crash either way.

can you get a backtrace from gphoto2 -a  using gdb and debuginfos? 

No, I can't.  I have no idea where to find debuginfo packages for the beta.

Created attachment 244117 [details]
stack trace from gdb, with gphoto/libgphoto2 debuginfo installed

OK, I found them.

puzzling.

seems the new libusb, will check

submitted fixed libusb-compat to Factory.

Confirmed on os11.1b2 x86_64 out of the box

And sent upstream:
http://sourceforge.net/mailarchive/forum.php?thread_name=1223478451.8074.4.camel%40hammer.suse.cz&forum_name=libusb-devel

stanislav, i had to add more NULL ptr checks, they are in
the same patch (fix-ctx-NULL.patch). ... can you also send them upstream?

*** Bug 435133 has been marked as a duplicate of this bug. ***

*** Bug 436753 has been marked as a duplicate of this bug. ***

I got a reply from upstream considering the fix possibly incorrect.

Reopening and decreasing to Normal to resolve this issue correctly. Changing the product to openSUSE to make it visible for upstream.

From: Daniel Drake <dsd@gentoo.org>
Cc: libusb-devel@lists.sourceforge.net
Subject: Re: [Libusb-devel] libusb-compat: Fix crash if usb not initialized (more crashes fixed)
Date: Sun, 02 Nov 2008 21:53:34 +0000 (22:53 CET)

Stanislav Brabec wrote:
> Stanislav Brabec wrote:
>> Attached patch fixes crash, if USB is not initialized.
> 
> And attached update fixes even more crashes, if USB is not initialized.
> It replaces previous one.

Thanks for the patch!

>> Affected application: F-Spot
>> Author: Marcus Meissner <meissner@suse.de>
>> Reference: https://bugzilla.novell.com/show_bug.cgi?id=432129

I have to sign up to see this bug report?

 From the 1 line description, it sounds like a F-Spot bug using libusb 
before it's initialized. I'm interested in matching the behaviour of 
libusb-0.1.12, but only if we do it precisely, which your patch doesn't 
quite do. For example, usb_close() on a NULL pointer will cause 
libusb-0.1.12 to crash, whereas your patch makes libusb-compat return 
-EINVAL.

Also, nitpicking: there are some coding style flaws, please try and 
match the rest of the file. Some of the patch is fine, some uses spaces 
for indentation and has 'if' conditions and bodies on the same line.

cheers
Daniel

Hmm.

I just went through all instances dereferencing the pointers. Some of them might be not necessary (like usb_open mentioned).

Here is a reply from Daniel Drake:

Stanislav Brabec wrote:
> Daniel Drake wrote:
>> From the 1 line description, it sounds like a F-Spot bug using libusb 
>> before it's initialized.
> 
> It may be a f-spot programming bug, which was hidden with libusb-0.1
> somehow. I am reopening it, so f-spot maintainers could review it.

If your "patch" fixes it, it sounds like it will just avoid a crash, and 
not actually fix the broken functionality.

>> I'm interested in matching the behaviour of 
>> libusb-0.1.12, but only if we do it precisely, which your patch doesn't 
>> quite do. For example, usb_close() on a NULL pointer will cause 
>> libusb-0.1.12 to crash, whereas your patch makes libusb-compat return 
>> -EINVAL.
> 
> So call abort() or so, isn't it?

I would just leave it as it was, which will crash. That's the same as 
libusb-0.1.

I would suggest finding the cause of your crash (which function in 
libusb-0.1 can be called before usb_init that doesn't crash) and 
matching behaviour there (if possible), and then looking for any similar 
cases, without being too bold.

Thanks,
Daniel

libusb-compat is not bug compatible with libusb0.

Reverting to libusb0, removing upper mentioned patch from libusb-compat.

Keeping this bug open and reassigning to GNOME team. It most probably indicates double close bug in f-spot.

Applications can still be built against libusb-1.0 using libusb-compat-devel instead of libusb-devel.

See bug 443861 for the whole story.

gphoto upstream bug https://sourceforge.net/tracker2/?func=detail&atid=108874&aid=2321764&group_id=8874

(In reply to comment #19)
> libusb-compat is not bug compatible with libusb0.
> 
> Reverting to libusb0, removing upper mentioned patch from libusb-compat.
> 
> Keeping this bug open and reassigning to GNOME team. It most probably indicates
> double close bug in f-spot.
> 
> Applications can still be built against libusb-1.0 using libusb-compat-devel
> instead of libusb-devel.

Hrm, but f-spot doesn't link to libusb AFAIK (at least, according to rpm -q --requires). So, hrm, should the bug really be in the GNOME team's hands?

See comment 19. Well, the problem may still exist in gphoto.

The crash was worked-around by return to libusb0 and later fixed in libusb-compat.

But the crash itself most probably indicates double close on error bug in gphoto.

Marcus, could you check gphoto code (of openSUSE 11.1)? If you think that the code is OK, feel free to close this bug.

11.2 Milestone7 ... f-sport works fine.

I did of course all gphoto2 apps with the new libusb ;)
f-spot crashed last week, but it does not