Closed
Bug 1019851
Opened 11 years ago
Closed 11 years ago
PROCESS-CRASH | /builds/slave/test/build/xpcshell/tests/mailnews/imap/test/unit/test_nsIMsgFolderListenerIMAP.js | application crashed [@ mozalloc_abort(char const*)]
Categories
(MailNews Core :: Testing Infrastructure, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird 32.0
People
(Reporter: jcranmer, Assigned: rkent)
Details
(Keywords: intermittent-failure)
Attachments
(1 file)
|
980 bytes,
patch
|
standard8
:
review+
|
Details | Diff | Splinter Review |
Exact regression date unknown, as there's been no debug builds since Thursday.
| Assignee | ||
Comment 1•11 years ago
|
||
I agreed to look at these and other Windows test failures. Many of them show crashes which are possibly the same root cause.
Assignee: nobody → kent
| Assignee | ||
Comment 2•11 years ago
|
||
These crashes are occurring because of a meaningless assert in nsImapMailFolder::GetFolderURL when called on a root folder. The odd thing is that the code is being called during do_check_neq(folder, null) while trying to stringify "folder" (which is NOT a root folder) so that it can print a debug error message, should it need to (which it does not need to). I have not idea why that generates a call to GetFolderURL for the root folder, the call stack is all xpcom code.
Any thoughts on just allowing the call as in this patch?
| Comment hidden (Legacy TBPL/Treeherder Robot) |
| Comment hidden (Legacy TBPL/Treeherder Robot) |
| Comment hidden (Legacy TBPL/Treeherder Robot) |
| Comment hidden (Legacy TBPL/Treeherder Robot) |
| Assignee | ||
Updated•11 years ago
|
Attachment #8433984 -
Flags: review?(standard8)
| Assignee | ||
Comment 7•11 years ago
|
||
At least one of these failures is also occurring in linux debug builds:
test_nsIMsgFolderListenerIMAP.js
I don't believe that the ASSERT here is meaningful. There is a reasonable response that can be given to a request for a folderURL for the root folder, and that is the URI of the root folder itself. As far as I can tell, this issue is coming up somehow in an attempt for javascript to stringify the XPCOM object as part of the test framework. I don't think it is worth trying to figure out why that is happening - but other opinions would be welcome.
See try run at https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=f4ae9b2e2189
| Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment 9•11 years ago
|
||
Comment on attachment 8433984 [details] [diff] [review]
1019851.patch
This feels reasonable to do, like you say, its a bit unclear what's happening, but I think this is safe enough.
Attachment #8433984 -
Flags: review?(standard8) → review+
| Assignee | ||
Comment 10•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 32.0
You need to log in
before you can comment on or make changes to this bug.
Description
•