462317 - Crash [@strlen][@icalmemory_strdup] when closing a recursive event

Status: VERIFIED FIXED

(Calendar :: Provider: GData, defect)

Description

[Mark Banner (:standard8)]

Attachment: stack

Using today's source code, c-c changeset 771:dc4edb5fe229, m-c changeset 21083:5c7b0c34e603:

1) Have a google calendar subscribed.
2) Open a recursive event, and select to open all events
3) Click on the x to close the window (doesn't appear to happen with the save & close button).
4) Crash.

Attaching stack

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

This seems like it might well be triggered by code other than the gData provider, marking tb-integration+.

Comment 2

[Stefan Sitter [:ssitter]]

Stack points to libical that was updated on 2008-10-26. 
Does the same issue exists using a nightly build from before 2008-10-26?

Comment 3

[Stefan Sitter [:ssitter]]

The crash happens when serializing a property according to the stack. Attachment 344814 [details] [diff] in Bug 394902 patched libical to allow reading empty properties. Is it possible that libical now fails when serializing that empty properties?

Comment 4

[Daniel Boelzle [:dbo]]

(In reply to comment #3)
> properties. Is it possible that libical now fails when serializing that empty
> properties?
I've tested that scenario at that time. The property has been filtered out.

Comment 5

[Daniel Boelzle [:dbo]]

Gdata provider reads custom privacy/CLASS values (e.g. DEFAULT) which is valid per RFC (http://tools.ietf.org/rfcmarkup?doc=draft-ietf-calsify-rfc2445bis-07#section-3.8.1.3); taking a look into libical.

Comment 6

[Daniel Boelzle [:dbo]]

Attachment: fix - v1

This is a bug in the libical wrapper code, and has shown in 0.9, too. But libical seems to behave more tolerant on branch and just omits such enum values, i.e. |CLASS:abc| will result in |CLASS:| when written.
I don't see a reason why we should preserve and fix that wrapper code, but just treat such properties as strings. BTW: calIIcalComponent::tranp seemed to be unused, but callers use calIItemBase::?etProperty("TRANSP",...).

The unit tests pass successfully, depending on fix in bug 458190.

Comment 7

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 345701 [details] [diff] [review]
fix - v1

Thanks for the patch, r=philipp

Comment 8

[Daniel Boelzle [:dbo]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/46da6c5e9740>

-> FIXED

Comment 9

[Mark Banner (:standard8)]

Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081105 Lightning/1.0pre Shredder/3.0b1pre and Lightning 20081105085021.

Comment 10

[Philipp Kewisch [:Fallen][📱📆]]

These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".