CPU utilization runs up to 100% when I try to make edits to a calendar (which don't get saved anyway).

RESOLVED WORKSFORME

Status

--
critical
RESOLVED WORKSFORME
16 years ago
12 years ago

People

(Reporter: paulbeard, Assigned: mikeypotter)

Tracking

Details

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2b) Gecko/20021116
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2b) Gecko/20021116

If I try to edit an event, I find not only can't I edit the event but mozilla
chews up all my CPU and the only way out is to kill it from a terminal. The
event I was trying to edit was a recurring event. 

Reproducible: Always

Steps to Reproduce:
1.select a recurring event.
2.extend the days it should occur on
3.your changes aren't made and you can't do anything else

Actual Results:  
I had to kill mozilla from the terminal. 

Expected Results:  
Um, saved the changes without making a big fuss about it.
(Reporter)

Comment 1

16 years ago
I should mention that my build came from the FreeBSD ports collection and is
FreeBSD native, not linux via the ABI layer. 
Summary: CPU utilization runs up to 100% when I try to make edits to a calendar (which don't get saved anyway). → CPU utilization runs up to 100% when I try to make edits to a calendar (which don't get saved anyway).

Comment 2

16 years ago
Paul, could I get some more-specic steps to reproduce this issue, what exact
settings are you using for recurring events?  Have you tried recent builds of
Mozilla and the Calendar?  Please give the calendar version in which you
experienced the error also.

Comment 3

16 years ago
From Paul:
It was with 1.2b (I'm using the version in the FreeBSD ports collection: there
is a ports code freeze pending a new OS release, so that's as far as I've gotten).

This may be fixed with the clearing of bugs 183667 and 167553. I'm trying to get
1.2.1 built from source to verify.
(Reporter)

Comment 4

16 years ago
well, I have mozilla 1.2.1 built but getting the calendar to build  is another
matter. 

In file included from oeICalEventImpl.h:41,
                 from oeICalEventImpl.cpp:47:
oeDateTimeImpl.h:43: ical.h: No such file or directory
In file included from oeICalEventImpl.cpp:47:
oeICalEventImpl.h:50: ical.h: No such file or directory
In file included from oeICalEventImpl.h:41,
                 from oeICalEventImpl.cpp:47:
oeDateTimeImpl.h:60: field `m_datetime' has incomplete type
In file included from oeICalEventImpl.cpp:47:
oeICalEventImpl.h:111: `icalcomponent' was not declared in this scope
oeICalEventImpl.h:111: `vcalendar' was not declared in this scope
oeICalEventImpl.h:112: syntax error before `*'
oeICalEventImpl.h:147: syntax error before `;'
oeICalEventImpl.h:152: field `m_lastalarmack' has incomplete type
oeICalEventImpl.h:174: field `m_displaydate' has incomplete type
oeICalEventImpl.h:175: field `m_displaydateend' has incomplete type
oeICalEventImpl.cpp:80: semicolon missing after declaration of `struct icaltimetype'
oeICalEventImpl.cpp: In function `int ConvertFromPrtime(long long int)':
oeICalEventImpl.cpp:81: variable `struct icaltimetype outdate' has initializer
but incomplete type
oeICalEventImpl.cpp:81: `icaltime_null_time' undeclared (first use this function)
oeICalEventImpl.cpp:81: (Each undeclared identifier is reported only once
oeICalEventImpl.cpp:81: for each function it appears in.)
oeICalEventImpl.cpp:96: confused by earlier errors, bailing out
cpp0: output pipe has been closed
gmake[2]: *** [oeICalEventImpl.o] Error 1
gmake[2]: Leaving directory `/usr/home/paul/src/mozilla/calendar/libxpical'
gmake[1]: *** [libs] Error 2
gmake[1]: Leaving directory `/usr/home/paul/src/mozilla/calendar'
gmake: *** [all] Error 2
(Reporter)

Comment 5

16 years ago
This version, built from CVS, won't run the calendar: the well-known regxpcom
bug shows up. 

Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3a) Gecko/20021207, build 2002120714

Obviously, I didn't use the right tag when I pulled from CVS: I'll fix that and
try again. 

1.2b (from the FreeBSD ports collection) will run the calendar (as installed
thru the XPI: I can't get it built from source).  After the autogen step, I get
an ltconfig error (
ltconfig: you must specify a host type if you use `--no-verify'
Try `ltconfig --help' for more information.
configure: error: libtool configure failed
). 

Anyway, CPU usage still spikes, but I can make edits and they do get saved. I
still see the count/recurrence problem I was seeing before, but that's because
I'm not able to use the new calendar code. 

I doubt this helps. If anyone has a hint on how to get the calendar built, let
me know. 

Comment 6

16 years ago
Since you say your edits are saved now, I will mark this as WORKSFORME.  If you
have trouble building calendar, open a new bug.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 7

16 years ago
I have built Mozilla with calendar from source on OS X and I still see some
inconsistencies with how calendar data is parsed/presented. I'll provide more
useful data presently. And once again I seem to have pulled from the tip instead
of the 1.2.1 release I meant to pull. Dunno how much difference that makes. I'll
try and square that up as well (what's a 4 hour build anyway?) 

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3a) Gecko/20021215

I gave up i386 on FreeBSD: there was too much port magic for me to figure out. 
The bugspam monkeys have been set free and are feeding on Calendar :: General. Be afraid for your sanity!
QA Contact: gurganbl → general
You need to log in before you can comment on or make changes to this bug.