Bug#668225: colord-sane thread-safety in wheezy
# let's have some version-tracking reassign 668225 colord found 668225 0.1.18-1 found 668225 0.1.21-1 fixed 668225 0.1.31-1 thanks Please use a Subject line that summarizes the subject of the email. I received Subject: Bug#668225: Wheezy talking about an unspecified bug out-of-context, and had to look up the bug report in order to have any idea what you were talking about :-) On 16/05/13 07:00, Christian Kastner wrote: Would it be possible to include [a fix for libdbus-related thread-safety problems in colord] in the next Wheezy point release (7.0.1)? I suspect the necessary changes to be rather too large for a stable update, given that the changelog describes it as a rewrite. However, a necessary first step would be for people who reliably get this crash to confirm that 0.1.31 actually fixes it. It looks as though a less intrusive fix for wheezy might be to drop the full SANE plugin and instead backport the udev-based cd-plugin-scanner module added by commit ebf3e961, which can detect local scanners but not networked ones: +# If we should use SANE to add scanner and camera devices. +# +# If SANE support is installed then this will allow colord to manage +# all scanners that SANE can detect, including remote scanners. +# +# If this is disabled then colord will only detect locally connected +# scanners. Another possibility for a lightweight workaround would be to set UseSANE to false in the default configuration file, which would result in colour correction for screens and printers but not scanners. I haven't had any response to the upstream libsane bug I opened querying some code used by colord-sane that uses threads but does not look thread-safe (https://alioth.debian.org/tracker/index.php?func=detailaid=313921group_id=30186atid=410366). Adding a call to dbus_threads_init_default() early in colord-sane's main() can't hurt, either. I'd categorize a process that segfaults at boot with a severity of at least important I would say that depends what that process does, and what effect the crash has. If a process crashes in the forest where nobody can hear it, did it make a sound? :-) S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668225: colord-sane thread-safety in wheezy
On 2013-05-16 09:47, Simon McVittie wrote: Please use a Subject line that summarizes the subject of the email. ACK On 16/05/13 07:00, Christian Kastner wrote: Would it be possible to include [a fix for libdbus-related thread-safety problems in colord] in the next Wheezy point release (7.0.1)? I suspect the necessary changes to be rather too large for a stable update, given that the changelog describes it as a rewrite. However, a necessary first step would be for people who reliably get this crash to confirm that 0.1.31 actually fixes it. I will try to confirm this over the weekend, but I too doubt that a rewrite will be accepted into a point release. It looks as though a less intrusive fix for wheezy might be to drop the full SANE plugin and instead backport the udev-based cd-plugin-scanner module added by commit ebf3e961, which can detect local scanners but not networked ones: +# If we should use SANE to add scanner and camera devices. +# +# If SANE support is installed then this will allow colord to manage +# all scanners that SANE can detect, including remote scanners. +# +# If this is disabled then colord will only detect locally connected +# scanners. Another possibility for a lightweight workaround would be to set UseSANE to false in the default configuration file, which would result in colour correction for screens and printers but not scanners. I haven't had any response to the upstream libsane bug I opened querying some code used by colord-sane that uses threads but does not look thread-safe (https://alioth.debian.org/tracker/index.php?func=detailaid=313921group_id=30186atid=410366). Adding a call to dbus_threads_init_default() early in colord-sane's main() can't hurt, either. I can't really add anything constructive to that. I don't even know how much this affects scanning (if at all). All I know is that colord is pulled in because some printing-related packages recommend it (interestingly, there is no dependency from xsane or sane-utils). I'd categorize a process that segfaults at boot with a severity of at least important I would say that depends what that process does, and what effect the crash has. If a process crashes in the forest where nobody can hear it, did it make a sound? :-) But is it really not heard by anyone? Definitely not by me (see above), beyond the syslog message. Strictly speaking, though, the package professes to provide a certain service, so if that services crashes at boot with no method of recovery, I'd say that fits the severity requirement of a bug which has a major effect on the usability of a package. But that's splitting hairs. As I said, I'll try to test 0.1.31 over the weekend, and I'm willing to test any other proposed fixes. Thanks, Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668225: colord-sane thread-safety in wheezy
On Fri, 17 May, 2013 at 8:45 AM, Christian Kastner deb...@kvr.at wrote: On 2013-05-16 09:47, Simon McVittie wrote: Please use a Subject line that summarizes the subject of the email. ACK On 16/05/13 07:00, Christian Kastner wrote: Would it be possible to include [a fix for libdbus-related thread-safety problems in colord] in the next Wheezy point release (7.0.1)? I suspect the necessary changes to be rather too large for a stable update, given that the changelog describes it as a rewrite. However, a necessary first step would be for people who reliably get this crash to confirm that 0.1.31 actually fixes it. I will try to confirm this over the weekend, but I too doubt that a rewrite will be accepted into a point release. It looks as though a less intrusive fix for wheezy might be to drop the full SANE plugin and instead backport the udev-based cd-plugin-scanner module added by commit ebf3e961, which can detect local scanners but not networked ones: +# If we should use SANE to add scanner and camera devices. +# +# If SANE support is installed then this will allow colord to manage +# all scanners that SANE can detect, including remote scanners. +# +# If this is disabled then colord will only detect locally connected +# scanners. Another possibility for a lightweight workaround would be to set UseSANE to false in the default configuration file, which would result in colour correction for screens and printers but not scanners. I haven't had any response to the upstream libsane bug I opened querying some code used by colord-sane that uses threads but does not look thread-safe (https://alioth.debian.org/tracker/index.php?func=detailaid=313921group_id=30186atid=410366). Adding a call to dbus_threads_init_default() early in colord-sane's main() can't hurt, either. This was done in colord 0.1.21-2 (and fixed for !Linux in -3); it fixes the dbus crash, but this leaves the fd-leak-resulting-in-100%-CPU-use-in-select() bug. Probably the best thing to do is to pull in 0.1.21-4. That has a number of miscellaneous fixes, and a rework of colord-sane that avoids all the problems. I should probably have pushed this past the freeze. Although that's a significant patch, it might be reasonable for a point release as the existing colord-sane is broken everywhere, so it's difficult to make things worse. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/debian-bugs-dist
