265076 - Calendar crashes when no calendars are active

Status: RESOLVED DUPLICATE of bug 254399

(Calendar :: Internal Components, defect)

Description

[Michael Hovis]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

An assert first occurs within nsVoidArray when the last active calendar is
de-selected, the crash (access violation) occurs soon afterwards.  The code
location in oeICalContainerImpl.cpp is (using the latest XulRunner Branch, but
have also seen this in other versions):

class oeCollectedEventEnumerator : public nsISimpleEnumerator
{
  public:
    NS_DECL_ISUPPORTS

    oeCollectedEventEnumerator(nsCOMArray<nsISimpleEnumerator>& aListOfEnums)
      : mListOfEnums(aListOfEnums),
        mEnumIndex(0)
    {
    }
    
    NS_IMETHOD HasMoreElements(PRBool *aResult) 
    {
      *aResult = PR_FALSE;
      mListOfEnums[mEnumIndex]->HasMoreElements(aResult);
      while (!*aResult && (++mEnumIndex < mListOfEnums.Count())) {
problem occurs here-->     mListOfEnums[mEnumIndex]->HasMoreElements(aResult);
      }
      return NS_OK;
    }

Reproducible: Always
Steps to Reproduce:
1.Uncheck all active calendars until there are no calendars selected
2.
3.

Actual Results:  
The entire application crashes

Expected Results:  
The visible calendar should just become empty - the app should be able to accept
that no calendars are active.

Comment 1

[Mostafa Hosseini]

That code is old and has been fixed in bug 254399.
What version of calendar is being used? Or which branch is being used to build
calendar? (Only trunk should be used)

*** This bug has been marked as a duplicate of 254399 ***

Comment 2

[Michael Hovis]

I've been using the xulrunner branch, so the version I'm at is 1.33 / 1.35. I
will assume that all the latest code for the calendar is coming out of the
Mozilla trunk from now on.

Comment 3

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

Yes, and it always has been trunk only.
(i wonder why you used the xulrunner branch for stuff other then testing xulrunner)

Comment 4

[Michael Hovis]

We were trying to resolve some Japanese issues and I looked at the history of
one of the localized Japanese files - in this case the latest version of the
file was synched w/ both the trunk and the xulrunner branch, I just made the
wrong choice.  When you do your calendar builds, do you just update to the
latest Mozilla trunk tree?

Comment 5

[Marcia Knous [:marcia]]

Mass move of libxpical bugs to the Internal Components, per ctalbert.

Comment 6

[Reed Loden [:reed]]

The bugspam monkeys have been set free and are feeding on Calendar :: Internal Components. Be afraid for your sanity!