351184 - Crash when copy and paste event after snooze [@ icaltime_from_timet_with_zone]

Status: VERIFIED FIXED

(Calendar :: Alarms, defect, critical)

Description

[Damian Szczepanik]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060902 Calendar/0.3a2+

problem with copy and paste event if it went into snooze mode

Reproducible: Always

Steps to Reproduce:
1. create new profile (really, don't try to reproduce with working profile!)
2. switch on alarm setting for event
3. move to multiweek view
4. create event for the day before yesterday
   -> calendar alarm dialos shows up
5. press Snooze
6. copy this event
7. click next day (yesterday) in main view and paste it
Actual Results:  
Sunbird crash, feedback agent is launching

TB22822303 and few previous reports also


after restart instead sunbird agent is launching again - I had to remove this profile forever

related bug 298358

Comment 1

[Damian Szczepanik]

this issue needs confirmation

Comment 2

[Stefan Sitter [:ssitter]]

No crash using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060902 Calendar/0.3a2+

Stack Trace for TB22822303:
  icaltime_from_timet_with_zone  
      [mozilla\calendar\libical\src\libical\icaltime.c, line 192]
  calDateTime::SetTimeInTimezone  
      [mozilla\calendar\base\src\caldatetime.cpp, line 340]
  calDateTime::SetNativeTime  
      [mozilla\calendar\base\src\caldatetime.cpp, line 238]
  XPTC_InvokeByIndex  
      [mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp, line 102]
  XPCWrappedNative::CallMethod  
      [mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 2162]

--> Same crash as in Bug 324293

The question is what triggers this crash here? Following shows the event that is in clipboard:

  BEGIN:VCALENDAR
  VERSION:2.0
  PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
  BEGIN:VEVENT
  CREATED:20060903T000719Z
  LAST-MODIFIED:20060903T000733Z
  DTSTAMP:20060903T000733Z
  SUMMARY:Test Event for Bug 351184
  PRIORITY:0
  CLASS:PUBLIC
  DTSTART;TZID=/mozilla.org/20050126_1/Europe/Berlin:20060828T110000
  DTEND;TZID=/mozilla.org/20050126_1/Europe/Berlin:20060828T130000
  X-MOZ-SNOOZE-TIME:2006/09/03 00:12:23 UTC
  BEGIN:VALARM
  TRIGGER;VALUE=DURATION:-PT15M
  X-MOZ-LASTACK:20060903T000723Z
  DESCRIPTION:Mozilla Alarm: Test Event for Bug 351184
  ACTION:DISPLAY
  END:VALARM
  END:VEVENT
  BEGIN:VTIMEZONE
  TZID:/mozilla.org/20050126_1/Europe/Berlin
  X-LIC-LOCATION:Europe/Berlin
  BEGIN:DAYLIGHT
  TZOFFSETFROM:+0100
  TZOFFSETTO:+0200
  TZNAME:CEST
  DTSTART:19700329T020000
  RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
  END:DAYLIGHT
  BEGIN:STANDARD
  TZOFFSETFROM:+0200
  TZOFFSETTO:+0100
  TZNAME:CET
  DTSTART:19701025T030000
  RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
  END:STANDARD
  END:VTIMEZONE
  END:VCALENDAR

The line
  X-MOZ-SNOOZE-TIME:2006/09/03 00:12:23 UTC
looks curious. I think this might be the reason.

Comment 3

[Joey Minta]

(In reply to comment #2)
> The line
>   X-MOZ-SNOOZE-TIME:2006/09/03 00:12:23 UTC
> looks curious. I think this might be the reason.
> 
Yes.  This indicates that the snooze-time isn't being serialized correctly.  It needs to go to ICS in the same way DTSTART does, otherwise this time will get converted in a semi-random way, often resulting in times that cross the 1970/2037 border.

Comment 4

[Adam Guthrie]

This should be marked as a dupe of bug 324293, then, no?

Comment 5

[Damian Szczepanik]

(In reply to comment #4)
> This should be marked as a dupe of bug 324293, then, no?
Why? Date that I set wasn't before 1970 or after 2038

Comment 6

[Stefan Sitter [:ssitter]]

Attachment: store snooze time as iCalendar DATETIME string

This patch should fix the real problem that lead to the crash finally. After that patch X-MOZ-SNOOZE-TIME is stored/read as proper iCalendar DATETIME string.

Note: This will probably break all snoozed events for users of the last few nightly builds since Bug 298358 landed.

Comment 7

[Matthew (lilmatt) Willis]

Comment on attachment 236594 [details] [diff] [review]
store snooze time as iCalendar DATETIME string

r1=lilmatt

Comment 8

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 236594 [details] [diff] [review]
store snooze time as iCalendar DATETIME string

This is a workaround, but good enough for now.
I filed bug 351330 for the real fix.

Comment 9

[Matthew (lilmatt) Willis]

Patch checked in on MOZILLA_1_8_BRANCH and trunk.

-> FIXED

(removing blocking request)

Comment 10

[Damian Szczepanik]

verified with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060905 Calendar/0.3a2+

Comment 11

[Stefan Sitter [:ssitter]]

If possible there should be a regression test case in Litmus for this issue.