1661992 - Crash on MOZ_ASSERT_UNREACHABLE of nsImapMockChannel::Suspend() in nsImapProtocol.cpp

Status: RESOLVED DUPLICATE of bug 217434

(Thunderbird :: General, defect)

Description

[gene smith]

When any email is opened the assert here https://searchfox.org/comm-central/rev/7156143da17c283114591163b3074e622484ee6e/mailnews/imap/src/nsImapProtocol.cpp#9618 occurs. If commented out, the assert right below on Resume() also occurs. With both asserts commented out I see no problem and tb runs fine. This is with just updated pristine trunk. This problem didn't occur on my last trunk pull/update a month ago.

Comment 1

[Magnus Melin [:mkmelin] (away until Aug 10)]

I think this is bug 217434 - but we don't know why it's a significant problem now and not before. Maybe the ParentProcessDocumentChannel stuff (bug 1633198).

Comment 2

[Daniel]

The current trunk is still busted with this issue. Here's a stack trace:

Assertion failure: false (MOZ_ASSERT_UNREACHABLE: nsImapMockChannel::Suspend), at Mozilla/Thunderbird/mozilla-unified/comm/mailnews/imap/src/nsImapProtocol.cpp:9638
#01: nsImapMockChannel::Suspend()[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0x30a669]
#02: mozilla::net::DocumentLoadListener::OnStartRequest(nsIRequest*)[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0xc656d1]
#03: mozilla::net::ParentChannelListener::OnStartRequest(nsIRequest*)[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0xb696f4]
#04: nsDocumentOpenInfo::OnStartRequest(nsIRequest*)[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0x146af3a]
#05: mozilla::net::ParentProcessDocumentOpenInfo::OnDocumentStartRequest(nsIRequest*)[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0xc76759]
#06: (anonymous namespace)::SyncRunnable1<nsIStreamListener, nsIRequest*>::Run()[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0x347f57]
#07: mozilla::RunnableTask::Run()[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0x648ac8]
#08: mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&)[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0x62b407]
#09: mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&)[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0x62a593]
#10: mozilla::TaskController::ProcessPendingMTTask(bool)[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0x62a62e]
#11: mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_0>::Run()[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0x64d5f7]
#12: nsThread::ProcessNextEvent(bool, bool*)[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0x63a2c0]
#13: NS_ProcessPendingEvents(nsIThread*, unsigned int)[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0x637ba6]
#14: nsBaseAppShell::NativeEventCallback()[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0x3b35e11]
#15: nsAppShell::ProcessGeckoEvents(void*)[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0x3bb1eba]
#16: __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__[/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x83d52]
#17: __CFRunLoopDoSource0[/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x83cf1]
#18: __CFRunLoopDoSources0[/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x83b0b]
#19: __CFRunLoopRun[/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x8283a]
#20: CFRunLoopRunSpecific[/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x81e3e]
#21: RunCurrentEventLoopInMode[/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x2fabd]
#22: ReceiveNextEventCommon[/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x2f7d5]
#23: _BlockUntilNextEventMatchingListInModeWithFilter[/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x2f579]
#24: _DPSNextEvent[/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x41039]
#25: -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:][/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x3f880]
#26: -[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:][Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0x3bb144f]
#27: -[NSApplication run][/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x3158e]
#28: nsAppShell::Run()[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0x3bb27ff]
#29: nsAppStartup::Run()[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0x5146086]
#30: XREMain::XRE_mainRun()[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0x5257aa6]
#31: XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&)[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0x5258cca]
#32: XRE_main(int, char**, mozilla::BootstrapConfig const&)[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/toolkit/library/build/XUL +0x52593bd]
#33: main[Mozilla/Thunderbird/mozilla-unified/obj-ff-dbg/dist/Thunderbird DailyDebug.app/Contents/MacOS/thunderbird +0x1633]

Is it common for the comm-central tree to be busted for an extended time? Should https://bugzilla.mozilla.org/show_bug.cgi?id=1655616 be reopened? How could I (or other volunteers) help?

Comment 3

[Magnus Melin [:mkmelin] (away until Aug 10)]

The tree is not usually busted for long. This bug is only affecting debug builds using imap, and we don't have UI tests for that so it's not a problem on continuous integration.

If you have ideas of how to fix it, do attach a patch or just your ideas. Maybe we just need to add no-op function for the imap mock channel.

But let's continue in bug 217434