If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED FIXED in 1.0b1

Status

Calendar
Provider: GData
--
critical
VERIFIED FIXED
9 years ago
6 years ago

People

(Reporter: standard8, Assigned: dbo)

Tracking

({crash})

Trunk
1.0b1
crash
Bug Flags:
blocking-calendar1.0 +
tb-integration +

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
Created attachment 345466 [details]
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
Flags: tb-integration?
This seems like it might well be triggered by code other than the gData provider, marking tb-integration+.
Flags: tb-integration? → tb-integration+
(Reporter)

Updated

9 years ago
Priority: -- → P1

Comment 2

9 years ago
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

9 years ago
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?
(Assignee)

Comment 4

9 years ago
(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.
(Assignee)

Comment 5

9 years ago
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.
Assignee: nobody → daniel.boelzle
Status: NEW → ASSIGNED
Flags: blocking-calendar1.0+
Priority: P1 → --
(Assignee)

Comment 6

9 years ago
Created attachment 345701 [details] [diff] [review]
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.
Attachment #345701 - Flags: review?(philipp)
Comment on attachment 345701 [details] [diff] [review]
fix - v1

Thanks for the patch, r=philipp
Attachment #345701 - Flags: review?(philipp) → review+
(Assignee)

Comment 8

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

-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
OS: Mac OS X → All
Hardware: PC → All
Resolution: --- → FIXED
Target Milestone: --- → 1.0
(Reporter)

Comment 9

9 years ago
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.
Status: RESOLVED → VERIFIED
Crash Signature: [@strlen] [@icalmemory_strdup]
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".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.