Open Bug 1780918 Opened 3 years ago Updated 2 years ago

Crash in [@ nsMapiAddressBook::~nsMapiAddressBook] via nsAbOutlookDirectory::GetCards entering 5 chars for the year on a new calendar event

Categories

(MailNews Core :: Address Book, defect)

Thunderbird 91
Desktop
Windows 10
defect

Tracking

(thunderbird_esr91 wontfix, thunderbird_esr102 affected)

UNCONFIRMED
Tracking Status
thunderbird_esr91 --- wontfix
thunderbird_esr102 --- affected

People

(Reporter: bugzilla, Unassigned)

References

()

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

There is no calendar component to select for the bug. Lightning used to be an addon so I selected addons. Please change if incorrect, thanks.


User accidently entered 5 chars for the year on a new calendar event and saved. The event vanished from the calendar. Clicked Events and Tasks > Find events > Searched for the event > Clicked on the calendar event > Thunderbird crashes.


Crash report: https://crash-stats.mozilla.org/report/index/643dd5b9-4813-448f-8467-ec04c0220523

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0 xul.dll nsMapiAddressBook::~nsMapiAddressBook mailnews/addrbook/src/nsMapiAddressBook.cpp:139
1 xul.dll nsMapiAddressBook::~nsMapiAddressBook mailnews/addrbook/src/nsMapiAddressBook.cpp:136
2 xul.dll nsAbOutlookDirectory::GetCards mailnews/addrbook/src/nsAbOutlookDirectory.cpp:878
3 xul.dll nsAbOutlookDirectory::ExecuteQuery mailnews/addrbook/src/nsAbOutlookDirectory.cpp:797
4 xul.dll nsAbOutlookDirectory::DoQuery mailnews/addrbook/src/nsAbOutlookDirectory.cpp:725
5 xul.dll nsAbOutlookDirectory::Search mailnews/addrbook/src/nsAbOutlookDirectory.cpp:765
6 xul.dll XPTC__InvokebyIndex 
7 None @0x00000075647fae37 
8 xul.dll _tailMerge_d3dcompiler_47.dll 
9 xul.dll static XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:1143
Component: Add-Ons: General → Address Book
Product: Thunderbird → MailNews Core
Keywords: crash
Severity: -- → S3
Summary: Crash in [@ nsMapiAddressBook::~nsMapiAddressBook] → Crash in [@ nsMapiAddressBook::~nsMapiAddressBook] entering 5 chars for the year on a new calendar event

So I tried to repro this on 103.0b6 and it didn't crash. But it also didn't error out either as, I would think, it should.

My STR:

  1. Create a new event for today, Title = Test
  2. For Start: and End (U): time, add an extra 2 at the end of the year so the dates in both areas is 7/23/20222
  3. Click Save and Close

Expected Result:
TB should complain that there's a date that's way too far in the future to be valid and to correct that date to a valid 4-digit year or just not pemit it

Actual Result:
After clicking Save and Close, something happens but no errors seem to show up. TB seems to have actually accepted the event date of 20222 but one cannot figure out IF it actually happened because if you make any attempt to try to go forward into the future (to the year 20222) via mini-month or Alt-3 by way of the "One Year Forward" button, TB will go into a state of Not Responding by the time you get to year 2048 and you have to End Task.

Now I don't know if I have an actual event set for 20222. =(

Error Console showed this when I tried:

07:37:19.797 Calendar: CalDAV: itemUri.spec = https://apidata.googleusercontent.com/caldav/v2/<removed>/events/1eea4bf8-68ce-404c-9fd5-20bf61b47b52.ics CalDavCalendar.jsm:599
07:37:19.801 Calendar: CalDAV: send: BEGIN:VCALENDAR

PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN

VERSION:2.0

BEGIN:VTIMEZONE

TZID:America/Chicago

BEGIN:DAYLIGHT

TZOFFSETFROM:-0600

TZOFFSETTO:-0500

TZNAME:CDT

DTSTART:19700308T020000

RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU

END:DAYLIGHT

BEGIN:STANDARD

TZOFFSETFROM:-0500

TZOFFSETTO:-0600

TZNAME:CST

DTSTART:19701101T020000

RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU

END:STANDARD

END:VTIMEZONE

BEGIN:VEVENT

CREATED:20220723T123705Z

LAST-MODIFIED:20220723T123719Z

DTSTAMP:20220723T123719Z

UID:1eea4bf8-68ce-404c-9fd5-20bf61b47b52

SUMMARY:test 3

DTSTART;TZID=America/Chicago:2022-0-23T0:0:0

DTEND;TZID=America/Chicago:2022-0-23T0:0:0

TRANSP:OPAQUE

END:VEVENT

END:VCALENDAR

CalDavCalendar.jsm:2425
07:37:19.806 Calendar: CalDAV: send (PUT https://apidata.googleusercontent.com/caldav/v2/<removed>/events/1eea4bf8-68ce-404c-9fd5-20bf61b47b52.ics): BEGIN:VCALENDAR

PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN

VERSION:2.0

BEGIN:VTIMEZONE

TZID:America/Chicago

BEGIN:DAYLIGHT

TZOFFSETFROM:-0600

TZOFFSETTO:-0500

TZNAME:CDT

DTSTART:19700308T020000

RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU

END:DAYLIGHT

BEGIN:STANDARD

TZOFFSETFROM:-0500

TZOFFSETTO:-0600

TZNAME:CST

DTSTART:19701101T020000

RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU

END:STANDARD

END:VTIMEZONE

BEGIN:VEVENT

CREATED:20220723T123705Z

LAST-MODIFIED:20220723T123719Z

DTSTAMP:20220723T123719Z

UID:1eea4bf8-68ce-404c-9fd5-20bf61b47b52

SUMMARY:test 3

DTSTART;TZID=America/Chicago:2022-0-23T0:0:0

DTEND;TZID=America/Chicago:2022-0-23T0:0:0

TRANSP:OPAQUE

X-MOZ-GOOGLE-HTML-DESCRIPTION:true

END:VEVENT

END:VCALENDAR

CalDavRequest.jsm:126
07:37:20.206 Calendar: CalDAV: Item added to <removed> successfully CalDavCalendar.jsm:613
07:37:20.208 Calendar: CalDAV: send(https://apidata.googleusercontent.com/caldav/v2/<removed>/events/): <?xml version="1.0" encoding="UTF-8"?>
<C:calendar-multiget xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"><D:prop><D:getetag/><C:calendar-data/></D:prop><D:href>/caldav/v2/<removed>/events/1eea4bf8-68ce-404c-9fd5-20bf61b47b52.ics</D:href></C:calendar-multiget> CalDavRequestHandlers.jsm:793
07:37:20.209 Calendar: CalDAV: send (REPORT https://apidata.googleusercontent.com/caldav/v2/<removed>/events/): <?xml version="1.0" encoding="UTF-8"?>
<C:calendar-multiget xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"><D:prop><D:getetag/><C:calendar-data/></D:prop><D:href>/caldav/v2/<removed>/events/1eea4bf8-68ce-404c-9fd5-20bf61b47b52.ics</D:href></C:calendar-multiget> CalDavRequest.jsm:126
07:37:20.336 Calendar: CalDAV: recv: null CalDavRequestHandlers.jsm:852
07:37:20.338 Calendar: CalDAV: recv: <D:multistatus><D:response><D:href>/caldav/v2/<removed>/events/1eea4bf8-68ce-404c-9fd5-20bf61b47b52.ics</D:href><D:propstat><D:status>HTTP/1.1 200 OK</D:status><D:prop><D:getetag>"63794263039"</D:getetag> CalDavRequest.jsm:145
07:37:20.364 Calendar: aChangeLogListener=undefined
calendarURI=https://apidata.googleusercontent.com/caldav/v2/<removed>/events/
iscached=true
this.mQueuedQueries.length=0 CalDavCalendar.jsm:1061

(In reply to Arthur K. [He/Him] from comment #1)

So I tried to repro this on 103.0b6 and it didn't crash. But it also didn't error out either as, I would think, it should.

Actual Result:
After clicking Save and Close, something happens but no errors seem to show up. TB seems to have actually accepted the event date of 20222 but one cannot figure out IF it actually happened because if you make any attempt to try to go forward into the future (to the year 20222) via mini-month or Alt-3 by way of the "One Year Forward" button, TB will go into a state of Not Responding by the time you get to year 2048 and you have to End Task.

Now I don't know if I have an actual event set for 20222. =(

You need to use Events and Tasks > Find Events and then enter "test". Then click on it.

Well, it doesn't seem to have actually created an event for the year 20222. Searching for the event named "test" for 20222 didn't actually show one. But the fact that I didn't get an error when I did a Save and Close means something happened that didn't cause an error, no?

(In reply to Arthur K. [He/Him] from comment #3)

Well, it doesn't seem to have actually created an event for the year 20222. Searching for the event named "test" for 20222 didn't actually show one. But the fact that I didn't get an error when I did a Save and Close means something happened that didn't cause an error, no?

Mine did show up when I entered the search term. I did not specify a date on the search. I'm on TB 91.11.0 64-bit.

Let me ask this question: What is the hard limit TB has as far as an allowable future event date that can be set? Since this would be limited by whatever Google allows on their side, it's safe to surmise 20222 wouldn't be valid, yes?

(In reply to Arthur K. [He/Him] from comment #5)

Let me ask this question: What is the hard limit TB has as far as an allowable future event date that can be set? Since this would be limited by whatever Google allows on their side, it's safe to surmise 20222 wouldn't be valid, yes?

So here's something interesting. To make a 5-digit event more searchable, I created a new event (using my STR) titled 20222 and then searched for it. TB did in fact create the event but saved it as occurring Sat. Sept. 06, 2021. Huh!? what do you guys make of that?

Can anyone on 103b repro?

Flags: needinfo?(de.berberich)
Flags: needinfo?(acdp)

I can't reproduce this issue.
When I create a new event for the year 20222, it won't be saved I presume..
A search with the title of the event won't find it.

Flags: needinfo?(de.berberich)

(In reply to Eckard Berberich from comment #7)

I can't reproduce this issue.
When I create a new event for the year 20222, it won't be saved I presume..
A search with the title of the event won't find it.

With which OS and TB version did you try?

No crash per se but I was able to repro using 104.0b2. Basically the same thing happens but now we get an error message (see image) about end and start dates not jiving. I created an event with title 20222 and after clicking Save & Close, I could Alt-3 and find the event title 20222 with a date of September 27, 2021.

I'm running macOS 10.14.6 and tested in TB 91.12.0.
Same result now when testing in TB 104.0b2. I presume the new event for 20222 cannot be saved in my macOS Thunderbird-Versions.

(In reply to Eckard Berberich from comment #9)

I'm running macOS 10.14.6 and tested in TB 91.12.0.
Same result now when testing in TB 104.0b2. I presume the new event for 20222 cannot be saved in my macOS Thunderbird-Versions.

So that makes me wonder why the event does save for me albeit as a past event (and not a future 20222 event). Realistically, it should accept a 5 digit date for a year and just throw an error to fix it or something.

Is there a debug or similar mode I can launch TB in to peek under the hood and see what actually happens the second I click Save & Close? TB should for any reason save a date 20,000 years into the future. Not even logically should it allow one to do so. They're working around around the Y2038 bug still, right? Surely the year 3,000 (or 10,000) bug has yet to be tackled in any software.

I am on 140.0b2 using new MBP 14" Monterey 12.5 en-UK

I made an event for 20222 no error, when saved and searched, shows me the date was reset to 2021!

Flags: needinfo?(acdp)

(In reply to Antony from comment #11)

I am on 140.0b2 using new MBP 14" Monterey 12.5 en-UK

I made an event for 20222 no error, when saved and searched, shows me the date was reset to 2021!

Ok so I am not the only one able to repro.

After having done this, you'll want to Alt-3 and go to your Calendar tab and click the Circle / Go To Today button or else that Calendar will forever be stuck on that 2021 date (bug 1766835).

I don't think this crash has anything to do with creating an event. Could be a coincidence. Technically, the year 20222 is a valid year.

There are some inconsistencies with the event dialog, for example; the year gets reset to two digits if I tab out of the field but I can type "20222", press enter and it will create the event. The calendar UI is being re-thought and the dialogs are one of the areas that should receive attention.

Summary: Crash in [@ nsMapiAddressBook::~nsMapiAddressBook] entering 5 chars for the year on a new calendar event → Crash in [@ nsMapiAddressBook::~nsMapiAddressBook] via nsAbOutlookDirectory::GetCards entering 5 chars for the year on a new calendar event
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: