Summary: | crash when calling CreateAccount with a malformed property | ||
---|---|---|---|
Product: | Telepathy | Reporter: | Tomeu Vizoso <tomeu> |
Component: | mission-control | Assignee: | Telepathy bugs list <telepathy-bugs> |
Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
Severity: | major | ||
Priority: | medium | Keywords: | patch |
Version: | git master | ||
Hardware: | Other | ||
OS: | All | ||
URL: | http://git.collabora.co.uk/?p=user/tomeu/telepathy-mission-control.git;a=shortlog;h=refs/heads/bug-27021 | ||
Whiteboard: | review+ | ||
i915 platform: | i915 features: |
Description
Tomeu Vizoso
2010-03-11 08:57:47 UTC
Not sure how to test this condition, suggestions most welcome. I don't think this patch is right. If set_error is non-NULL, you'll copy it into cad->error, then use g_set_error to put an MCD_ACCOUNT_MANAGER_ERROR into cad->error, leading to a GLib assertion failure. What you probably want to do is to have set_new_account_properties() put its error into a temporary variable, which is then propagated into cad->error? Or don't call g_set_error if cad->error is already non-NULL? Or refactor the function so that cad->ok and cad->error are always set at the same time, reducing confusion considerably? Or something. Reworked branch following the comments Can you reproduce this crash in a regression test by attempting to set a nonexistent parameter name over D-Bus, for instance?
(To be honest, your stack trace looks as though there's been a missing NUL termination further down the stack, so you're fixing symptoms rather than causes. However, if the same symptom can be caused in a valid way, there's no harm in fixing *that* bug.)
This patch is rather less obvious than it could be... it might well be *valid*, but I think it'd be considerably clearer if expressed like this:
> refactor the
> function so that cad->ok and cad->error are always set at the same time
Something like this:
cad->ok = TRUE;
if (set_error != NULL)
{
cad->ok = FALSE;
/* moved from [A] */
g_set_error (&cad->error, blah blah blah, set_error->message);
}
if (cad->ok && cad->properties != NULL)
{
cad->ok = ... as before ... (&cad->error);
}
if (cad->ok)
{
... as before ...
}
else
{
/* [A] */
complete_account_creation_finish (account, TRUE, cad);
}
(The comments mentioning [A] wouldn't be committed, obviously.)
(For a relatively simple change like this that's been rewritten during review, I'd also be inclined to rebase your branch on master then squash the various attempts at it into a single patch, rather than having a branch containing a wrong patch, a revert, a merge from master, etc.) (In reply to comment #4) > Can you reproduce this crash in a regression test by attempting to set a > nonexistent parameter name over D-Bus, for instance? A non-existent property name makes it crash, yes: diff --git a/test/twisted/account-manager/create-with-properties.py b/test/twisted/account-manager/create-with-properties.py index bfd5b2b..3849524 100644 --- a/test/twisted/account-manager/create-with-properties.py +++ b/test/twisted/account-manager/create-with-properties.py @@ -71,6 +71,7 @@ def test(q, bus, mc): creation_properties = dbus.Dictionary({ cs.ACCOUNT + '.Enabled': True, + cs.ACCOUNT + '.NonExistent': 'foo', cs.ACCOUNT + '.AutomaticPresence': dbus.Struct(( dbus.UInt32(cs.PRESENCE_TYPE_BUSY), 'busy', 'Exploding'), signature='uss'), What would be better, a new test in its own module, or one more test inside account-manager/create-with-properties.py ? > (To be honest, your stack trace looks as though there's been a missing NUL > termination further down the stack, so you're fixing symptoms rather than > causes. However, if the same symptom can be caused in a valid way, there's no > harm in fixing *that* bug.) I'm confused, AFAICS the crash is caused because when the parameters are valid but the properties are invalid, the code incorrectly tries to propagate the params error, which doesn't exist. > This patch is rather less obvious than it could be... it might well be *valid*, > but I think it'd be considerably clearer if expressed like this: > > > refactor the > > function so that cad->ok and cad->error are always set at the same time > > Something like this: > > cad->ok = TRUE; > > if (set_error != NULL) > { > cad->ok = FALSE; > /* moved from [A] */ > g_set_error (&cad->error, blah blah blah, set_error->message); > } > > if (cad->ok && cad->properties != NULL) > { > cad->ok = ... as before ... (&cad->error); > } > > if (cad->ok) > { > ... as before ... > } > else > { > /* [A] */ > complete_account_creation_finish (account, TRUE, cad); > } > > (The comments mentioning [A] wouldn't be committed, obviously.) Sounds good, thanks. Thanks, that looks much better. Please commit (Tollef has set up ACLs so people in group 'telepathy', like you, should be able to commit to MC). This appears to be fixed in master. |
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.