GNOME Bugzilla – Bug 665244
new cheese camera device monitor crashes Empathy
Last modified: 2011-12-02 08:21:12 UTC
This cheese commit breaks Empathy: http://git.gnome.org/browse/cheese/commit/?id=054a929303468353537442b4ba77590449c90a73 Cheese used to emit signals like this: g_signal_emit (monitor, monitor_signals[ADDED], 0, devpath, device_file, product_name, v4l_version); but now it does this: CheeseCameraDevice *device = cheese_camera_device_monitor_set_up_device (udevice); g_signal_emit (monitor, monitor_signals[ADDED], 0, device); where cheese_camera_device_monitor_set_up_device does CheeseCameraDevice *device = cheese_camera_device_new (devpath, device_file, product_name, v4l_version, &error); Empathy could get all the required fields from the CheeseCameraDevice structure, but this change breaks the ABI. I'm not sure who should address the issue: - Empathy can from now on depend on a new libcheese and update itself - Cheese rewrite the patch to support bot old-style signals and add new signals to address the new-style I'm also worried about existing Empathy clients running on systems that update only libcheese. On those systems old Empaty clients will crash, won't they? Unfortunately Cheese released 3.3.2 containing this patch.
Similarly this patch http://git.gnome.org/browse/cheese/commit/?id=9e2f1e18387e2d492715c6e6ae9aac1829751531 commit 9e2f1e18387e2d492715c6e6ae9aac1829751531 Author: David King <amigadave@amigadave.com> Date: Sun Nov 6 16:13:10 2011 +0100 Improve CheeseEffect documentation Document the private methods in CheeseEffect. Simplify effect construction, by making the name and pipeline-desc properties construct-only. Improve some variables names. Does this: CheeseEffect * -cheese_effect_new (void) +cheese_effect_new (const gchar *name, const gchar *pipeline_desc) breaking Empathy compilation with new Cheese. The fix is very simple for Empathy, but is the ABI breakage allowed?
(In reply to comment #1) > breaking Empathy compilation with new Cheese. The fix is very simple for > Empathy, but is the ABI breakage allowed? During development releases, yes. For guidance on this, see the release planning wiki page: http://live.gnome.org/ReleasePlanning/Freezes#API.2BAC8-ABI_Freeze which for the 3.3 cycle corresponds to a API/ABI freeze date of 6th February 2012: http://live.gnome.org/ThreePointThree#Schedule Cheese is not strictly part of the development platform, but I intend to stick to the freeze nonetheless. For Cheese 3.3.2, the libtool library version was bumped to indicate an ABI-incompatible change for both libcheese and libcheese-gtk: http://git.gnome.org/browse/cheese/commit/?id=73975f712b4161a44ec98ef670093d23e8b665db This means that an Empathy version linked against an old libcheese will not run with a new libcheese version (in response to comment #0). I also updated the Cheese API reference to indicate that the API is currently unstable, and is likely to change again in the future: http://developer.gnome.org/cheese/unstable/CheeseCameraDeviceMonitor.html
Actually, I was mistaking: Empathy has copy-pasted camera detection from cheese. I guess I was getting segfaults because I was building it with libcheese and I think the linker gave priority to libcheese rather than libempathy to some symbols. But should Empathy keep it's own copy-pasted sources for cheese-camera-detection? Or at least when WITH_CHEESE is true, shouldn't it drop it's own copy-pasted ones from the tree?
I'm having crashes too when adding/removing USB camera. I've built a Call enable empathy for Fedora.
Created attachment 202498 [details] Backtrace
Build with --with-cheese=no workaround the issue. I see three solutions to this, 1) rename the internal copy 2) don't link empathy-call to libcheese, as this process does not really need it 3) Simply use cheese library.
3) isn't really an option, Ubuntu does't build with Cheese (it's not on the CD) and I want them to have camera detection anyway. I think that 1) is the proper solution and 2) is good to do that anyway.
Humm actually only libempathy-gtk is linking on libcheese (used in the avatar code) but that doesn't solve our problem as empathy-call needs to link on libempathy and libempathy-gtk anyway. So 2) it is.
@Guillaume: I'm working on my gsoc patches to bring effects to empathy-call. They will need libcheese linked to emapthy-call. I think there's room for a 4) if with-cheese=yes don't use the internal copy, but the one from libcheese.
Created attachment 202507 [details] [review] renamespace CheeseCameraDeviceMonitor This ensures empathy will always use our version, even when linking on libcheese, and so avoid incompatibliy when libcheese breaks its ABI.
Raluca, Nicolas: could one of you test and review this patch please?
(In reply to comment #9) > @Guillaume: I'm working on my gsoc patches to bring effects to empathy-call. > They will need libcheese linked to emapthy-call. Great! So yeah we need to be able to link on it anyway. > I think there's room for a 4) if with-cheese=yes don't use the internal copy, > but the one from libcheese. That won't work as libcheese may have a different API/ABI than our internal copy.
(In reply to comment #12) > That won't work as libcheese may have a different API/ABI than our internal > copy. That can be address by updating Empathy to the current Cheese version, can't it? Eh, I'm sure there are other things at stake and that you know better :)
Yeah that would work but means we'll have this problem back as soon as libcheese's API/ABI changes again. Another argument is that I prefer to have all versions using the same code (much easier to debug issues). Note that I'd be happy to update our own copy of this code but ideally I'd prefer to wait that the API is frozen for 3.4 first.
Review of attachment 202507 [details] [review]: Looks good.
(In reply to comment #9) > @Guillaume: I'm working on my gsoc patches to bring effects to empathy-call. > They will need libcheese linked to emapthy-call. > > I think there's room for a 4) if with-cheese=yes don't use the internal copy, > but the one from libcheese. Honestly I would not use cheese effect, but ratter something faster like GstFilter (not yet merge though). The idea is that to add/remove effect with cheese you need to turn off/on the camera, which take a lot of time with certain USB UVC camera. See http://gstconf.ubicast.tv/videos/gstreamer-and-farsight/ for more info. Guillaume, I didn't tested it yet, but I'm not worried, that will definitely work.
Attachment 202507 [details] pushed as 0fdc280 - renamespace CheeseCameraDeviceMonitor