Bug 39778 - if colord service is not available to dbus , gnome-settings-daemon segfault in libcolord
Summary: if colord service is not available to dbus , gnome-settings-daemon segfault i...
Status: RESOLVED FIXED
Alias: None
Product: colord
Classification: Unclassified
Component: client (show other bugs)
Version: unspecified
Hardware: Other All
: medium minor
Assignee: Richard Hughes
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-02 14:58 UTC by Alban Browaeys
Modified: 2011-08-11 01:33 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
debug trace showing the two calls and the segfault (9.33 KB, text/plain)
2011-08-02 14:58 UTC, Alban Browaeys
Details
libcolord : remove the first call to complete (972 bytes, patch)
2011-08-02 15:04 UTC, Alban Browaeys
Details | Splinter Review

Description Alban Browaeys 2011-08-02 14:58:52 UTC
Created attachment 49851 [details]
debug trace showing the two calls and the segfault

There are two calls to g_simple_async complete in cd_client_connect_cb libcolord/cd-client.c
on master when connection fails.
Ie complete in the client->priv->proxy == NULL case then in the out label there is a call to
complete_in_idle.
As the cd_client_connect_finish free the error the second calls leads to segfault when the caller
of the finish attempt to read the error message.
Comment 1 Alban Browaeys 2011-08-02 15:04:15 UTC
Created attachment 49852 [details] [review]
libcolord : remove the first call to complete
Comment 2 Richard Hughes 2011-08-03 00:47:20 UTC
Great find, thanks!

A couple of questions:

1. In your opionion, do you think it makes more sense to nuke the first g_simple_async_result_complete() or just to move the second g_simple_async_result_complete_in_idle() above the "out:" line? We don't really need to complete in idle if there's no proxy result to wait around for.

2. How did you reproduce this bug? How did you make it so that colord was installed, but not "available"? I'm asking so that I could add something into the self tests so that this kind of bug doesn't happen again.

Thanks,

Richard.
Comment 3 Alban Browaeys 2011-08-03 07:21:46 UTC
(In reply to comment #2)
> 1. In your opionion, do you think it makes more sense to nuke the first
> g_simple_async_result_complete() or just to move the second
> g_simple_async_result_complete_in_idle() above the "out:" line? We don't really
> need to complete in idle if there's no proxy result to wait around for.

Moving _idle above the out line looks better, you are right.
 
> 2. How did you reproduce this bug? How did you make it so that colord was
> installed, but not "available"? I'm asking so that I could add something into
> the self tests so that this kind of bug doesn't happen again.

The use case I had was installing calord into a location which I had not told dbus about before my first test. Thus activation always fail. Then I fixed it by includig the location in system-local.conf and session-local.conf .
I think the test case could be about g_simple_async_result cb and finish only, ie checking that error is not null after finish . There might not be a need to reproduce the exact use case.
Comment 4 Richard Hughes 2011-08-03 07:26:10 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > 1. In your opionion, do you think it makes more sense to nuke the first
> > g_simple_async_result_complete() or just to move the second
> > g_simple_async_result_complete_in_idle() above the "out:" line? We don't really
> > need to complete in idle if there's no proxy result to wait around for.
> 
> Moving _idle above the out line looks better, you are right.

If you give me a trivial patch for that, you'll get credit in the NEWS file :-)

> I think the test case could be about g_simple_async_result cb and finish only,
> ie checking that error is not null after finish . There might not be a need to
> reproduce the exact use case.

Right, makes sense. Thanks dude.
Comment 5 Richard Hughes 2011-08-11 01:33:49 UTC
I've adapted your patch and pushed this to master. Thanks.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.