Closed Bug 1145983 Opened 10 years ago Closed 9 years ago

Thunderbird crashes when a filter copies an email to an IMAP subfolder

Categories

(MailNews Core :: Filters, defect)

x86_64
Linux
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: bill_chris, Unassigned)

References

Details

(Keywords: crash)

Crash Data

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 Build ID: 20150306140254 Steps to reproduce: 1. Make a filter that copies any email received at my Earthlink email to a subfolder in my GMail account. 2. Be in the subfolder and receive an email that gets copied to that folder. Actual results: Thunderbird crashes. Expected results: Thunderbird should not crash.
Crashes, as in aborts? If so, please attach a stacktrace with thunderbird symbols https://developer.mozilla.org/de/docs/How_to_get_a_stacktrace_for_a_bug_report#Linux or is it a hang, as in stops responding and you must kill it?
Yes, Thunderbird completely shuts down and I have to bring it back up again. I tried following the directions at the page you gave me, and it submitted a bug report to Launchpad.net. Here is the link to that bug report. Let me know if that's not enough and you need anything else. https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1434889
Thanks. Perhaps the same as bug 871622. Is step #2 a neccessary requirement for Thunderbird to crash, i.e. if you are not in the folder then it does not crash?
Severity: normal → critical
Status: UNCONFIRMED → NEW
Crash Signature: [@ nsCOMPtr_base::~nsCOMPtr_base | nsTArray_Impl<nsCOMPtr<nsIUrlListener>, nsTArrayInfallibleAllocator>::RemoveElementsAt ]
Depends on: 871622
Ever confirmed: true
Flags: needinfo?(bill_chris)
Keywords: crash
Yes. If you are not in the IMAP folder, it will not crash.
Flags: needinfo?(bill_chris)
(almost broke my own rule of to not leave confirmed bugs in Untriage component)
Component: Untriaged → Filters
Product: Thunderbird → MailNews Core
Crash Signature: [@ nsCOMPtr_base::~nsCOMPtr_base | nsTArray_Impl<nsCOMPtr<nsIUrlListener>, nsTArrayInfallibleAllocator>::RemoveElementsAt ] → [@ nsCOMPtr_base::~nsCOMPtr_base | nsTArray_Impl<nsCOMPtr<nsIUrlListener>, nsTArrayInfallibleAllocator>::RemoveElementsAt ] [@ nsCOMPtr_base::~nsCOMPtr_base | nsTArray_Impl<T>::RemoveElementsAt ]
As of 38.4.0, this appears to no longer be an issue.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.