Dbus call timeout handled

Dbus call timeout handled

BUG=chromium-os:15496
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=86806

[glotov, 2011-05-25 15:31:55]

Hello Steven,

this change must hotfix the crashes mentioned in the bug.
As we cannot reproduce the crash locally, it is hard to track the real reason. I
guess that dbus path of the object may have gone while the call was in progress.
Please advice if you have more ideas.

[stevenjb, 2011-05-25 18:02:37]

This change looks fine, but looking at the issue, one thing I can imagine
causing this is an empty device path. I'm not sure why it might be empty, but I
would also add a check for device_path().empty() here:

http://www.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/chrome/browser/chrom...

[glotov, 2011-05-25 18:25:06]

Do you think that empty path may drive DBus mad this way? Should I check it?

Can it be so that Flimflam registered the path, then Chrome tried to call
GetProperties() for that path and, at the same instance, the path was
unregistered? Just a guess. Because path here is a reference to mobile
network discovered. They come and go...

On Wed, May 25, 2011 at 10:02 PM, <stevenjb@chromium.org> wrote:

> This change looks fine, but looking at the issue, one thing I can imagine
> causing this is an empty device path. I'm not sure why it might be empty,
> but I
> would also add a check for device_path().empty() here:
>
>
>
http://www.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/chrome/browser/chrom...
>
>
>
> http://codereview.chromium.org/7031052/
>



-- 
Thank you,
Denis

[glotov, 2011-05-25 18:29:33]

And regarding this change, should it be committed?

BTW, to fix <unknown> log domain by DBus, we may add G_LOG_DOMAIN="DBus" to the
compilation of dbus-glib package. Worth the effort?

[stevenjb, 2011-05-25 18:59:11]

An empty path is unlikely, but it might cause a DBus crash, so I figure it is
worth checking. It could also be an edge case, but the path here is for a mobile
device (not service), which shouldn't normally be disappearing on us. 

We should probably move the MonitorSMS calls to NetworkLibrary and create a
wrapper function that checks that the device path is not empty and is still in
the list of devices (device_map_) before calling MonitorSMS. Does that make
sense? If not you can re-assign the issue to me once you've pushed this change
and I will make the other change and have you review it.

Adding the correct log domain for DBus seems like it would be worthwhile; I
doubt this will be our last DBus issue.

We can push this CL as-is, but lets not close the issue until we add the other
checks.

LGTM