Closed Bug 229916 Opened 21 years ago Closed 18 years ago

calendar (and mozilla) crash if many alarms expired while calendar was closed

Categories

(Calendar :: General, defect)

Product:
Calendar
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: tambaytushar, Assigned: mostafah)

References

Details

(Keywords: crash) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

i have 6 to 7 weekly alarms. if i  close calndar and then open it after about 10
days (maybe sooner) a lot of these alarms have expired while the calendar is
closed. 

during calendar startup in this situation, i hear 5 to 6 beeps (i guess for
expired alarms) and then the entire mozilla application (including calendar)
crashes.

this also happens if non recurring alarms have expired.

Reproducible: Always

Steps to Reproduce:
1. setup 7 or 8  weekly alarms 
2. close mozilla 
3. advance date on the machine by 10 days
4.  startup mozilla / calendar

Actual Results:  
mozilla and calendar crashed

Expected Results:  
given me notice that the alarms had expired

a simple work around for this is to go and manually edit the
CalendarDataFile.ics (whch is is XML format) and just bump the 
X-MOZILLA-LASTALARMACK entry to the current date.

i see the build identifier hasn't identified the calendar version i am using. 
it is the latest one available  (the 26th sept 2003 build) -->  Mozilla Calendar
2003092613-cal

i searched through bugzilla for something similar  and the only bug that came
close is #145855. but comments indicate that it has been closed long back. i am
surprised to be the first one reporting this ...
(In reply to comment #0)

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114
I have also experienced this annoying bug. I have found it in revisions
1.4.1, 1.5., 1.5.1 and 1.6 under Suse Linux 8.2.
Let's hope a kind soul can correct it as soon as possible.

Regards,
JP



I can confirm this, it's very simple to reproduce:
1. Create a new event in the past (e.g. yesterday) and enable the alarm
2. Click OK in the Event Edit dialog; the alarm window will pop up immediately
3. If you acknowledge the alarm, or all alarms, Mozilla crashes.

If the calendar file is remotely held on an webdav server, the alarm pops up on
every restart of Mozilla, if the calendar file is just locally, it's OK at the
next start.

Happened with Mozilla 1.6 and Calendar 20040109 XPI.
*** Bug 239412 has been marked as a duplicate of this bug. ***
Confirming crash. The crash also happens if one tries to subscribe to a remote
calendar and Calendar attempts to fire many old alarms.

One backtrace that I saw (from a crash at startup) was

One stack trace I saw was:

#0  0x008ae364 in _int_malloc () from /lib/libc.so.6
#1  0x008ad7ff in malloc () from /lib/libc.so.6
#2  0x00445527 in g_malloc () from /usr/lib/libglib-2.0.so.0
#3  0x0073325b in gdk_region_rectangle () from /usr/lib/libgdk-x11-2.0.so.0
#4  0x00751321 in expose_serial_predicate () from /usr/lib/libgdk-x11-2.0.so.0
#5  0x0074fda6 in gdk_window_scroll () from /usr/lib/libgdk-x11-2.0.so.0
#6  0x0075d8e8 in gdk_window_resize () from /usr/lib/libgdk-x11-2.0.so.0
#7  0x00c05aac in moz_drawingarea_resize (drawingarea=0xa692690, width=71610281,
height=195392064) at mozdrawingarea.c:188
#8  0x00c0ab61 in nsWindow::NativeResize(int, int, int) (this=0xb9b5f78,
aWidth=71610281, aHeight=71610280, aRepaint=1)
    at nsWindow.cpp:2336
#9  0x00c0fe33 in nsCommonWidget::Resize(int, int, int) (this=0xb9b5f78,
aWidth=71610281, aHeight=71610280, aRepaint=1)
    at nsCommonWidget.cpp:307
#10 0x04a95f0e in nsView::SetDimensions(nsRect const&, int) (this=0xa81a570,
aRect=@0x1c, aPaint=1) at nsUnitConversion.h:159
#11 0x04a98c2a in nsViewManager::SetWindowDimensions(int, int) (this=0xb7aee38,
aWidth=1074154155, aHeight=1074154140)
    at nsViewManager.cpp:660
#12 0x04a9b783 in nsViewManager::DispatchEvent(nsGUIEvent*, nsEventStatus*)
(this=0xb7aee38, aEvent=0xfeba145c,
    aStatus=0xfeba13f8) at nsUnitConversion.h:149
#13 0x04a951a8 in HandleEvent (aEvent=0xfeba145c) at nsView.h:243
#14 0x00c0fc06 in nsCommonWidget::DispatchEvent(nsGUIEvent*, nsEventStatus&)
(this=0xb9b5f78, aEvent=0xfeba145c,
    aStatus=@0xfeba1458) at nsCommonWidget.cpp:214
#15 0x00c0fb7b in nsCommonWidget::DispatchResizeEvent(nsRect&, nsEventStatus&)
(this=0x1, aRect=@0x958940, aStatus=@0xfeba14c8)
    at nsCommonWidget.cpp:200
#16 0x00c0fdc3 in nsCommonWidget::Resize(int, int, int) (this=0xb9b5f78,
aWidth=71610277, aHeight=71610276, aRepaint=1)
    at nsCommonWidget.cpp:318
#17 0x04a95f0e in nsView::SetDimensions(nsRect const&, int) (this=0xa81a570,
aRect=@0x1c, aPaint=1) at nsUnitConversion.h:159
#18 0x04a98c2a in nsViewManager::SetWindowDimensions(int, int) (this=0xb7aee38,
aWidth=1074154095, aHeight=1074154080)
    at nsViewManager.cpp:660
#19 0x04a9b783 in nsViewManager::DispatchEvent(nsGUIEvent*, nsEventStatus*)
(this=0xb7aee38, aEvent=0xfeba16bc,
    aStatus=0xfeba1658) at nsUnitConversion.h:149
#20 0x04a951a8 in HandleEvent (aEvent=0xfeba16bc) at nsView.h:243
#21 0x00c0fc06 in nsCommonWidget::DispatchEvent(nsGUIEvent*, nsEventStatus&)
(this=0xb9b5f78, aEvent=0xfeba16bc,
    aStatus=@0xfeba16b8) at nsCommonWidget.cpp:214
#22 0x00c0fb7b in nsCommonWidget::DispatchResizeEvent(nsRect&, nsEventStatus&)
(this=0x1, aRect=@0x958940, aStatus=@0xfeba1728)
    at nsCommonWidget.cpp:200
#23 0x00c0fdc3 in nsCommonWidget::Resize(int, int, int) (this=0xb9b5f78,
aWidth=71610273, aHeight=71610272, aRepaint=1)
    at nsCommonWidget.cpp:318
#24 0x04a95f0e in nsView::SetDimensions(nsRect const&, int) (this=0xa81a570,
aRect=@0x1c, aPaint=1) at nsUnitConversion.h:159
#25 0x04a98c2a in nsViewManager::SetWindowDimensions(int, int) (this=0xb7aee38,
aWidth=1074154035, aHeight=1074154020)
    at nsViewManager.cpp:660
#26 0x04a9b783 in nsViewManager::DispatchEvent(nsGUIEvent*, nsEventStatus*)
(this=0xb7aee38, aEvent=0xfeba191c,
    aStatus=0xfeba18b8) at nsUnitConversion.h:149
#27 0x04a951a8 in HandleEvent (aEvent=0xfeba191c) at nsView.h:243
#28 0x00c0fc06 in nsCommonWidget::DispatchEvent(nsGUIEvent*, nsEventStatus&)
(this=0xb9b5f78, aEvent=0xfeba191c,
    aStatus=@0xfeba1918) at nsCommonWidget.cpp:214
#29 0x00c0fb7b in nsCommonWidget::DispatchResizeEvent(nsRect&, nsEventStatus&)
(this=0x1, aRect=@0x958940, aStatus=@0xfeba1988)
    at nsCommonWidget.cpp:200
#30 0x00c0fdc3 in nsCommonWidget::Resize(int, int, int) (this=0xb9b5f78,
aWidth=71610269, aHeight=71610268, aRepaint=1)
    at nsCommonWidget.cpp:318
...
and so on in a loop.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
*** Bug 247094 has been marked as a duplicate of this bug. ***
I saw that two, but with only two alarms.
every time there are more then 2 events alarm at startup the calendar crashes
Mozilla completely.
On WinXP with the 2004111214-cal build, I do not see an outright crash but the
Mozilla suite hangs.  If several alarms have expired since Calendar was last
open, it apparently goes into a loop when opened.  After a few seconds, a never
ending series of Javascript "This script is taking too long; should it be
aborted?" confirm dialogs start to appear but it is usually impossible to
dismiss them all and regain control of the suite.  I use end up editing the
CalendarDataFile.ics file and modifying the X-MOZILLA-LASTALARMACK values, which
is inconvenient.

Note that I have email notification configured for most alarms.  Maybe that
makes things a little different.
I had the same problem (hanging, etc.) described by Mark Smith
on the Windows 2000 version:
2004111713-cal
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv.1.8a5)
Gecko/20041122
This is a bug which has to be fixed, but I found a work-around
for testers, so you don't have to reset the date, etc.
Open the browser, then Edit | Preferences | Calendar | Alarms,
and uncheck the "Show missed alarms" checkbox.
I've seen this bug with all versions of calendar since mozilla 1.3 (in fact, I
keep a copy of mozilla 1.3 around with the calendar installed just so I can run
it and acknowledge alarms then close it and start the newer version of the calendar.

Anytime calendar starts with >1 pending alarm, it crashes the calendar.
My current calendar:
mozilla calendar
2004092412-cal
mozilla/5.0(X11;u;linux i686;en-US;rv:1.7.3)Gecko/20040914

The version that works because it doesn't open alarms when it starts.  I open
this calendar and even with pending alarms, none go off.  But if I open an even
and then click OK whether I change the event or not, it fires off the alarm
notifications without crashing.  Then I acknowled or snooze the alarms and open
the new calendar again and it works fine.
mozilla calendar 2003061213-cal
mozilla/5.0 (x11;u;linux i686;en-us;rv:1.3)gecko/20030312
*** Bug 243610 has been marked as a duplicate of this bug. ***
*** Bug 292703 has been marked as a duplicate of this bug. ***
QA Contact: gurganbl → general
*** Bug 321496 has been marked as a duplicate of this bug. ***
I have the same problem as well. this is a thunderbird calendar extension (version 1.0.7 (20051017) - Calendar 2005011113 on 2.6.11-kanotix-11
Fixed in the latest nightly builds.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.