Closed Bug 1475166 Opened 6 years ago Closed 6 years ago

TEST-UNEXPECTED-FAIL | comm/mailnews/jsaccount/test/unit/test_jaMsgFolder.js

Categories

(MailNews Core :: Backend, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 64.0

People

(Reporter: jorgk-bmo, Unassigned)

References

Details

(Whiteboard: [Thunderbird-testfailure: X Windows only][Thunderbird-disabled-test])

Attachments

(1 file)

TEST-UNEXPECTED-FAIL | comm/mailnews/jsaccount/test/unit/test_jaMsgFolder.js | xpcshell return code: 0 or in debug: TEST-UNEXPECTED-FAIL | comm/mailnews/jsaccount/test/unit/test_jaMsgFolder.js | xpcshell return code: 1 PID 4512 | testJaMsgProtocolInfoAssertion failure: false (MOZ_ASSERT_UNREACHABLE: nsMsgIncomingServer superclass not implementing GetLocalStoreType!), at z:/build/build/src/comm/mailnews/base/util/nsMsgIncomingServer.cpp:1006 PROCESS-CRASH | comm/mailnews/jsaccount/test/unit/test_jaMsgFolder.js | application crashed [@ nsMsgIncomingServer::GetLocalStoreType(nsTSubstring<char> &)] This appeared after switching from MS VS C++ to clang-cl, see bug 1474878 and bug 1443590.
Whiteboard: [Thunderbird-testfailure: X Windows only]
Actually, the MOZ_ASSERT_UNREACHABLE at nsMsgIncomingServer.cpp:1006 used to be a NS_NOTYETIMPLEMENTED: https://hg.mozilla.org/comm-central/rev/6c8dea328d6d#l3.12 Just a mystery why that only fails on Windows and just after we switched compilers from MS VS C++ to clang-cl. Seems fishy.
Attached file 1475166-crash.txt (deleted) —
mach xpcshell-test comm/mailnews/jsaccount/test/unit/test_jaMsgFolder.js doesn't fail locally. https://taskcluster-artifacts.net/NXVSRcR5S_2W8bljhCSIDA/0/public/logs/live_backing.log gives this stack (attached). Looks like Kent's magic broke down once again, like in bug 1447492 and all I can do here is switch off the test for Windows.
Keywords: leave-open
Whiteboard: [Thunderbird-testfailure: X Windows only] → [Thunderbird-testfailure: X Windows only][Thunderbird-disabled-test]
Pushed by mozilla@jorgk.com: https://hg.mozilla.org/comm-central/rev/a6cd3f2e51c9 temporarily disable crashing test test_jaMsgFolder.js on Windows. rs=bustage-fix DONTBUILD
Comment from dev-platform: On 13/07/2018 03:10, Anthony Jones wrote: Changing the compiler will change all the timing characteristics. This can reliably produce different outcomes on race conditions. We've seen some of that. You're likely to be seeing the same thing.
Looking at the call stack, it looks like this code is being called: https://dxr.mozilla.org/comm-central/rev/e5e1510b8d914bfa8439b21ba3f73e4f2e83e957/mailnews/base/util/nsMsgIncomingServer.cpp#1006 If this indeed doesn't happen with MSVC, this could indicate a miscompilation bug that could also affect real users. It may be worth spending time to reduce the difference in the MSVC vs clang-cl build in the test.
Hi Ehsan. Yes, the code at nsMsgIncomingServer.cpp#1006 triggers the crash in a debug build. We run this test on three platforms, and it has never failed there before. So I assume the mis-compilation bug is for clang-cl and not MSVC. These are the first few lines of the stack: 00:05:52 INFO - PID 4512 | testJaMsgProtocolInfoAssertion failure: false (MOZ_ASSERT_UNREACHABLE: nsMsgIncomingServer superclass not implementing GetLocalStoreType!), at z:/build/build/src/comm/mailnews/base/util/nsMsgIncomingServer.cpp:1006 00:06:04 INFO - PID 4512 | #01: mozilla::mailnews::JaCppIncomingServerDelegator::Super::GetLocalStoreType(nsTSubstring<char> &) [comm/mailnews/jsaccount/src/JaIncomingServer.h:71] 00:06:04 INFO - PID 4512 | #02: mozilla::mailnews::JaCppIncomingServerDelegator::GetLocalStoreType(nsTSubstring<char> &) [comm/mailnews/jsaccount/src/JaIncomingServer.h:53] Sadly JaIncomingServer.h:71 and JaIncomingServer.h:53 is C++ trickery I don't understand: https://dxr.mozilla.org/comm-central/rev/e5e1510b8d914bfa8439b21ba3f73e4f2e83e957/mailnews/jsaccount/src/JaIncomingServer.h#71 https://dxr.mozilla.org/comm-central/rev/e5e1510b8d914bfa8439b21ba3f73e4f2e83e957/mailnews/jsaccount/src/JaIncomingServer.h#53 Could it have gone wrong there already? So where from here?
I don't know anything about this code. Just wanted to point out that this may end up being a crasher bug that would affect users... I trust your judgement on what to do about it, I think Thunderbird itself is too big of a test case to file an upstream llvm.org/bugs bug about, so it may require finding someone who's either familiar with the code or able to devote some time to understand what's going differently in clang-cl compiled binaries.
Will be fixed by bug 1498392. Thanks, Neil! Ehsan, no clang-cl compiler error.
Status: NEW → RESOLVED
Closed: 6 years ago
Keywords: leave-open
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 64.0
Version: 60 → 63
Pushed by mozilla@jorgk.com: https://hg.mozilla.org/comm-central/rev/056b4d7d3d6b Backed out changeset a6cd3f2e51c9 to re-enable test after fix provided in bug 1498392. a=backout
Depends on: 1498392
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: