assertion failure loadinfo

VERIFIED FIXED in Thunderbird 37.0

Status

--
critical
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: ishikawa, Assigned: hiro)

Tracking

(4 keywords)

Trunk
Thunderbird 37.0
x86_64
All
crash, dogfood, regression, topcrash-thunderbird
Dependency tree / graph

Thunderbird Tracking Flags

(thunderbird37? fixed, seamonkey2.34? fixed)

Details

(Whiteboard: [startup crash], crash signature)

Attachments

(5 attachments, 7 obsolete attachments)

(Reporter)

Description

4 years ago
I refreshed thunderbird soruce code (C-C) yesterday, and
encountered crash when I ran it on a console.
After the startup, when I click on a subject line in the subject summary window to see the content of a message, TB crashed.
The crash occrus on line 700 of
comm-central/mozilla/netwerk/base/src/nsIOService.cpp


  692	    if ((aLoadingNode || aLoadingPrincipal) && newChannel2Succeeded) {
  693	      // Make sure that all the individual protocolhandlers attach
  694	      // a loadInfo within it's implementation of ::newChannel2().
  695	      // Once Bug 1087720 lands, we should remove the surrounding
  696	      // if-clause here and always assert that we indeed have a
  697	      // loadinfo on the newly created channel.
  698	      nsCOMPtr<nsILoadInfo> loadInfo;
  699	      (*result)->GetLoadInfo(getter_AddRefs(loadInfo));
  700	      MOZ_ASSERT(loadInfo);
  701	
  702	      // If we're sandboxed, make sure to clear any owner the channel
  703	      // might already have.
  704	      if (loadInfo->GetLoadingSandboxed()) {
  705	        (*result)->SetOwner(nullptr);
  706	      }
  707	    }
  708	


Here is the error log and decoded stack backtrace from the full DEBUG version of TB (I compiled TB with -DDEBUG).

Incorporate message begin:
uidl string: 00000f77533eeb2c
Incorporate message complete.
Incorporate message begin:
uidl string: 00000f78533eeb2c
Incorporate message complete.
End mail message delivery.
--DOMWINDOW == 31 (0x3036ed0) [pid = 22110] [serial = 17] [outer = (nil)] [url = about:blank]
--DOMWINDOW == 30 (0x328c530) [pid = 22110] [serial = 18] [outer = (nil)] [url = about:blank]
--DOMWINDOW == 29 (0x32d11e0) [pid = 22110] [serial = 19] [outer = (nil)] [url = about:blank]
--DOMWINDOW == 28 (0x28a1cf0) [pid = 22110] [serial = 15] [outer = (nil)] [url = about:blank]
--DOMWINDOW == 27 (0x2fb67c0) [pid = 22110] [serial = 16] [outer = (nil)] [url = about:blank]
--DOMWINDOW == 26 (0x1422740) [pid = 22110] [serial = 2] [outer = (nil)] [url = about:blank]
--DOMWINDOW == 25 (0x34b4600) [pid = 22110] [serial = 27] [outer = (nil)] [url = chrome://messenger/content/multimessageview.xhtml]
--DOMWINDOW == 24 (0x332a2e0) [pid = 22110] [serial = 20] [outer = (nil)] [url = about:blank]
--DOMWINDOW == 23 (0x3a75060) [pid = 22110] [serial = 29] [outer = (nil)] [url = chrome://messenger/content/systemIntegrationDialog.xul]
--DOMWINDOW == 22 (0x3a77180) [pid = 22110] [serial = 30] [outer = (nil)] [url = about:blank]
Assertion failure: loadInfo, at /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp:700
#01: nsDocShell::DoURILoad(nsIURI*, nsIURI*, bool, unsigned int, nsISupports*, char const*, nsAString_internal const&, nsIInputStream*, nsIInputStream*, bool, nsIDocShell**, nsIRequest**, bool, bool, bool, nsAString_internal const&, nsIURI*, unsigned int) (/REF-OBJ-DIR/objdir-tb3/docshell/base/../../dist/include/nsCOMPtr.h:686)
#02: nsDocShell::InternalLoad(nsIURI*, nsIURI*, unsigned int, nsISupports*, unsigned int, char16_t const*, char const*, nsAString_internal const&, nsIInputStream*, nsIInputStream*, unsigned int, nsISHEntry*, bool, nsAString_internal const&, nsIDocShell*, nsIURI*, nsIDocShell**, nsIRequest**) (/REF-COMM-CENTRAL/comm-central/mozilla/docshell/base/nsDocShell.cpp:10143)
#03: nsDocShell::LoadURI(nsIURI*, nsIDocShellLoadInfo*, unsigned int, bool) [clone .part.322] (/REF-COMM-CENTRAL/comm-central/mozilla/docshell/base/nsDocShell.cpp:1633)
#04: nsMailboxService::FetchMessage(char const*, nsISupports*, nsIMsgWindow*, nsIUrlListener*, char const*, int, char const*, nsIURI**) (/REF-OBJ-DIR/objdir-tb3/mailnews/local/src/../../../dist/include/nsCOMPtr.h:390)
#05: nsMailboxService::DisplayMessage(char const*, nsISupports*, nsIMsgWindow*, nsIUrlListener*, char const*, nsIURI**) (/REF-COMM-CENTRAL/comm-central/mailnews/local/src/nsMailboxService.cpp:275)
#06: nsMessenger::OpenURL(nsACString_internal const&) (/REF-OBJ-DIR/objdir-tb3/mailnews/base/src/../../../dist/include/nsTSubstring.h:95)
#07: nsMsgDBView::LoadMessageByViewIndex(unsigned int) (/REF-OBJ-DIR/objdir-tb3/mailnews/base/src/../../../dist/include/nsTArray.h:330)
#08: nsMsgGroupView::LoadMessageByViewIndex(unsigned int) (/REF-COMM-CENTRAL/comm-central/mailnews/base/src/nsMsgGroupView.cpp:900)
#09: nsMsgDBView::SelectionChanged() (/REF-COMM-CENTRAL/comm-central/mailnews/base/src/nsMsgDBView.cpp:1190)
#10: NS_InvokeByIndex (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp:166)
#11: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1736)
#12: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1174)
#13: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jscntxtinlines.h:232)
#14: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:482)
#15: Interpret(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:2539)
#16: js::RunScript(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:432)
#17: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:501)
#18: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:538)
#19: JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jsapi.cpp:4955)
#20: mozilla::dom::EventHandlerNonNull::Call(JSContext*, JS::Handle<JS::Value>, mozilla::dom::Event&, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&) (/REF-OBJ-DIR/objdir-tb3/dom/bindings/EventHandlerBinding.cpp:258)
#21: mozilla::JSEventHandler::HandleEvent(nsIDOMEvent*) (/REF-OBJ-DIR/objdir-tb3/dom/events/../../dist/include/js/RootingAPI.h:799)
#22: mozilla::EventListenerManager::HandleEventSubType(mozilla::EventListenerManager::Listener*, nsIDOMEvent*, mozilla::dom::EventTarget*) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventListenerManager.cpp:976)
#23: mozilla::EventListenerManager::HandleEventInternal(nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent**, mozilla::dom::EventTarget*, nsEventStatus*) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventListenerManager.cpp:1122)
#24: mozilla::EventTargetChainItem::HandleEventTargetChain(nsTArray<mozilla::EventTargetChainItem>&, mozilla::EventChainPostVisitor&, mozilla::EventDispatchingCallback*, mozilla::ELMCreationDetector&) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventDispatcher.cpp:210)
#25: mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsCOMArray<mozilla::dom::EventTarget>*) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventDispatcher.cpp:638)
#26: mozilla::EventDispatcher::DispatchDOMEvent(nsISupports*, mozilla::WidgetEvent*, nsIDOMEvent*, nsPresContext*, nsEventStatus*) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventDispatcher.cpp:698)
#27: nsINode::DispatchEvent(nsIDOMEvent*, bool*) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/base/nsINode.cpp:1273)
#28: mozilla::AsyncEventDispatcher::Run() (/REF-OBJ-DIR/objdir-tb3/dom/events/../../dist/include/nsCOMPtr.h:390)
#29: nsContentUtils::AddScriptRunner(nsIRunnable*) (/REF-OBJ-DIR/objdir-tb3/dom/base/../../dist/include/nsCOMPtr.h:390)
#30: mozilla::AsyncEventDispatcher::RunDOMEventWhenSafe() (/REF-OBJ-DIR/objdir-tb3/dom/events/../../dist/include/nsRefPtr.h:59)
#31: nsTreeSelection::FireOnSelectHandler() (/REF-OBJ-DIR/objdir-tb3/layout/xul/tree/../../../dist/include/nsRefPtr.h:59)
#32: nsTreeSelection::Select(int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeSelection.cpp:386)
#33: NS_InvokeByIndex (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp:166)
#34: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1736)
#35: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1174)
#36: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jscntxtinlines.h:232)
#37: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:482)
#38: Interpret(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:2539)
#39: js::RunScript(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:432)
#40: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:501)
#41: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:538)
#42: JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jsapi.cpp:4955)
#43: mozilla::dom::EventHandlerNonNull::Call(JSContext*, JS::Handle<JS::Value>, mozilla::dom::Event&, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&) (/REF-OBJ-DIR/objdir-tb3/dom/bindings/EventHandlerBinding.cpp:258)
#44: mozilla::JSEventHandler::HandleEvent(nsIDOMEvent*) (/REF-OBJ-DIR/objdir-tb3/dom/events/../../dist/include/js/RootingAPI.h:799)
#45: nsXBLPrototypeHandler::ExecuteHandler(mozilla::dom::EventTarget*, nsIDOMEvent*) (/REF-OBJ-DIR/objdir-tb3/dom/xbl/../../dist/include/nsCOMPtr.h:698)
#46: nsXBLEventHandler::HandleEvent(nsIDOMEvent*) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/xbl/nsXBLEventHandler.cpp:52)
#47: mozilla::EventListenerManager::HandleEventSubType(mozilla::EventListenerManager::Listener*, nsIDOMEvent*, mozilla::dom::EventTarget*) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventListenerManager.cpp:976)
#48: mozilla::EventListenerManager::HandleEventInternal(nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent**, mozilla::dom::EventTarget*, nsEventStatus*) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventListenerManager.cpp:1122)
#49: mozilla::EventTargetChainItem::HandleEventTargetChain(nsTArray<mozilla::EventTargetChainItem>&, mozilla::EventChainPostVisitor&, mozilla::EventDispatchingCallback*, mozilla::ELMCreationDetector&) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventDispatcher.cpp:210)
#50: mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsCOMArray<mozilla::dom::EventTarget>*) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventDispatcher.cpp:638)
#51: PresShell::HandleEventInternal(mozilla::WidgetEvent*, nsEventStatus*) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsPresShell.cpp:8252)
#52: PresShell::HandlePositionedEvent(nsIFrame*, mozilla::WidgetGUIEvent*, nsEventStatus*) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsPresShell.cpp:7958)
#53: PresShell::HandleEvent(nsIFrame*, mozilla::WidgetGUIEvent*, bool, nsEventStatus*) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsPresShell.cpp:7758)
#54: nsViewManager::DispatchEvent(mozilla::WidgetGUIEvent*, nsView*, nsEventStatus*) (/REF-OBJ-DIR/objdir-tb3/view/../dist/include/nsCOMPtr.h:390)
#55: nsView::HandleEvent(mozilla::WidgetGUIEvent*, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/view/nsViewManager.h:32)
#56: nsWindow::DispatchEvent(mozilla::WidgetGUIEvent*, nsEventStatus&) (/REF-COMM-CENTRAL/comm-central/mozilla/widget/gtk/nsWindow.cpp:479)
#57: nsWindow::OnButtonPressEvent(_GdkEventButton*) (/REF-COMM-CENTRAL/comm-central/mozilla/widget/gtk/nsWindow.cpp:2756)
#58: button_press_event_cb(_GtkWidget*, _GdkEventButton*) (/REF-COMM-CENTRAL/comm-central/mozilla/widget/gtk/nsWindow.cpp:5315)
#59: gtk_marshal_VOID__UINT_STRING (/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0)
#60: g_closure_invoke (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0)
#61: g_signal_handler_disconnect (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0)
#62: g_signal_emit_valist (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0)
#63: g_signal_emit (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0)
#64: gtk_widget_translate_coordinates (/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0)
#65: gtk_propagate_event (/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0)
#66: gtk_main_do_event (/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0)
#67: gdk_event_get_graphics_expose (/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0)
#68: g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0)
#69: g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0)
#70: g_main_context_iteration (/lib/x86_64-linux-gnu/libglib-2.0.so.0)
#71: nsAppShell::ProcessNextNativeEvent(bool) (/REF-COMM-CENTRAL/comm-central/mozilla/widget/gtk/nsAppShell.cpp:156)
#72: nsBaseAppShell::DoProcessNextNativeEvent(bool, unsigned int) (/REF-COMM-CENTRAL/comm-central/mozilla/widget/nsBaseAppShell.cpp:140)
#73: nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool, unsigned int) (/REF-COMM-CENTRAL/comm-central/mozilla/widget/nsBaseAppShell.cpp:298)
#74: nsThread::ProcessNextEvent(bool, bool*) (/REF-OBJ-DIR/objdir-tb3/xpcom/threads/../../dist/include/nsTArray.h:330)
#75: NS_ProcessNextEvent(nsIThread*, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/nsThreadUtils.cpp:265)
#76: mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (/REF-COMM-CENTRAL/comm-central/mozilla/ipc/glue/MessagePump.cpp:140)
#77: MessageLoop::RunInternal() (/REF-COMM-CENTRAL/comm-central/mozilla/ipc/chromium/src/base/message_loop.cc:234)
#78: MessageLoop::Run() (/REF-COMM-CENTRAL/comm-central/mozilla/ipc/chromium/src/base/message_loop.cc:508)
#79: nsBaseAppShell::Run() (/REF-COMM-CENTRAL/comm-central/mozilla/widget/nsBaseAppShell.cpp:166)
#80: nsAppStartup::Run() (/REF-COMM-CENTRAL/comm-central/mozilla/toolkit/components/startup/nsAppStartup.cpp:282)
#81: XREMain::XRE_mainRun() (/REF-COMM-CENTRAL/comm-central/mozilla/toolkit/xre/nsAppRunner.cpp:4154)
#82: XREMain::XRE_main(int, char**, nsXREAppData const*) (/REF-COMM-CENTRAL/comm-central/mozilla/toolkit/xre/nsAppRunner.cpp:4229)
#83: XRE_main (/REF-COMM-CENTRAL/comm-central/mozilla/toolkit/xre/nsAppRunner.cpp:4449)
#84: do_main(int, char**, nsIFile*) (/REF-COMM-CENTRAL/comm-central/mail/app/nsMailApp.cpp:188)
#85: main (/REF-COMM-CENTRAL/comm-central/mail/app/nsMailApp.cpp:400)
#86: __libc_start_main (/home/aurel32/glibc/glibc-2.19/csu/libc-start.c:321)
#87: _start (/REF-OBJ-DIR/objdir-tb3/dist/bin/thunderbird)
#88: ??? (???:???)

Program /REF-OBJ-DIR/objdir-tb3/dist/bin/thunderbird (pid = 22110) received signal 11.
Stack:
#01: __restore_rt (sigaction.c:?)
#02: nsIOService::NewChannelFromURIWithProxyFlags2(nsIURI*, nsIURI*, unsigned int, nsIDOMNode*, nsIPrincipal*, nsIPrincipal*, unsigned int, unsigned int, nsIChannel**) (/REF-OBJ-DIR/objdir-tb3/netwerk/base/src/../../../dist/include/nsILoadInfo.h:97)
#03: nsIOService::NewChannelFromURI2(nsIURI*, nsIDOMNode*, nsIPrincipal*, nsIPrincipal*, unsigned int, unsigned int, nsIChannel**) (/REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp:595)
#04: nsDocShell::DoURILoad(nsIURI*, nsIURI*, bool, unsigned int, nsISupports*, char const*, nsAString_internal const&, nsIInputStream*, nsIInputStream*, bool, nsIDocShell**, nsIRequest**, bool, bool, bool, nsAString_internal const&, nsIURI*, unsigned int) (/REF-OBJ-DIR/objdir-tb3/docshell/base/../../dist/include/nsCOMPtr.h:686)
#05: nsDocShell::InternalLoad(nsIURI*, nsIURI*, unsigned int, nsISupports*, unsigned int, char16_t const*, char const*, nsAString_internal const&, nsIInputStream*, nsIInputStream*, unsigned int, nsISHEntry*, bool, nsAString_internal const&, nsIDocShell*, nsIURI*, nsIDocShell**, nsIRequest**) (/REF-COMM-CENTRAL/comm-central/mozilla/docshell/base/nsDocShell.cpp:10143)
#06: nsDocShell::LoadURI(nsIURI*, nsIDocShellLoadInfo*, unsigned int, bool) [clone .part.322] (/REF-COMM-CENTRAL/comm-central/mozilla/docshell/base/nsDocShell.cpp:1633)
#07: nsMailboxService::FetchMessage(char const*, nsISupports*, nsIMsgWindow*, nsIUrlListener*, char const*, int, char const*, nsIURI**) (/REF-OBJ-DIR/objdir-tb3/mailnews/local/src/../../../dist/include/nsCOMPtr.h:390)
#08: nsMailboxService::DisplayMessage(char const*, nsISupports*, nsIMsgWindow*, nsIUrlListener*, char const*, nsIURI**) (/REF-COMM-CENTRAL/comm-central/mailnews/local/src/nsMailboxService.cpp:275)
#09: nsMessenger::OpenURL(nsACString_internal const&) (/REF-OBJ-DIR/objdir-tb3/mailnews/base/src/../../../dist/include/nsTSubstring.h:95)
#10: nsMsgDBView::LoadMessageByViewIndex(unsigned int) (/REF-OBJ-DIR/objdir-tb3/mailnews/base/src/../../../dist/include/nsTArray.h:330)
#11: nsMsgGroupView::LoadMessageByViewIndex(unsigned int) (/REF-COMM-CENTRAL/comm-central/mailnews/base/src/nsMsgGroupView.cpp:900)
#12: nsMsgDBView::SelectionChanged() (/REF-COMM-CENTRAL/comm-central/mailnews/base/src/nsMsgDBView.cpp:1190)
#13: NS_InvokeByIndex (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp:166)
#14: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1736)
#15: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1174)
#16: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jscntxtinlines.h:232)
#17: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:482)
#18: Interpret(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:2539)
#19: js::RunScript(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:432)
#20: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:501)
#21: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:538)
#22: JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jsapi.cpp:4955)
#23: mozilla::dom::EventHandlerNonNull::Call(JSContext*, JS::Handle<JS::Value>, mozilla::dom::Event&, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&) (/REF-OBJ-DIR/objdir-tb3/dom/bindings/EventHandlerBinding.cpp:258)
#24: mozilla::JSEventHandler::HandleEvent(nsIDOMEvent*) (/REF-OBJ-DIR/objdir-tb3/dom/events/../../dist/include/js/RootingAPI.h:799)
#25: mozilla::EventListenerManager::HandleEventSubType(mozilla::EventListenerManager::Listener*, nsIDOMEvent*, mozilla::dom::EventTarget*) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventListenerManager.cpp:976)
#26: mozilla::EventListenerManager::HandleEventInternal(nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent**, mozilla::dom::EventTarget*, nsEventStatus*) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventListenerManager.cpp:1122)
#27: mozilla::EventTargetChainItem::HandleEventTargetChain(nsTArray<mozilla::EventTargetChainItem>&, mozilla::EventChainPostVisitor&, mozilla::EventDispatchingCallback*, mozilla::ELMCreationDetector&) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventDispatcher.cpp:210)
#28: mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsCOMArray<mozilla::dom::EventTarget>*) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventDispatcher.cpp:638)
#29: mozilla::EventDispatcher::DispatchDOMEvent(nsISupports*, mozilla::WidgetEvent*, nsIDOMEvent*, nsPresContext*, nsEventStatus*) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventDispatcher.cpp:698)
#30: nsINode::DispatchEvent(nsIDOMEvent*, bool*) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/base/nsINode.cpp:1273)
#31: mozilla::AsyncEventDispatcher::Run() (/REF-OBJ-DIR/objdir-tb3/dom/events/../../dist/include/nsCOMPtr.h:390)
#32: nsContentUtils::AddScriptRunner(nsIRunnable*) (/REF-OBJ-DIR/objdir-tb3/dom/base/../../dist/include/nsCOMPtr.h:390)
#33: mozilla::AsyncEventDispatcher::RunDOMEventWhenSafe() (/REF-OBJ-DIR/objdir-tb3/dom/events/../../dist/include/nsRefPtr.h:59)
#34: nsTreeSelection::FireOnSelectHandler() (/REF-OBJ-DIR/objdir-tb3/layout/xul/tree/../../../dist/include/nsRefPtr.h:59)
#35: nsTreeSelection::Select(int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeSelection.cpp:386)
#36: NS_InvokeByIndex (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp:166)
#37: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1736)
#38: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1174)
#39: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jscntxtinlines.h:232)
#40: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:482)
#41: Interpret(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:2539)
#42: js::RunScript(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:432)
#43: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:501)
#44: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:538)
#45: JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jsapi.cpp:4955)
#46: mozilla::dom::EventHandlerNonNull::Call(JSContext*, JS::Handle<JS::Value>, mozilla::dom::Event&, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&) (/REF-OBJ-DIR/objdir-tb3/dom/bindings/EventHandlerBinding.cpp:258)
#47: mozilla::JSEventHandler::HandleEvent(nsIDOMEvent*) (/REF-OBJ-DIR/objdir-tb3/dom/events/../../dist/include/js/RootingAPI.h:799)
#48: nsXBLPrototypeHandler::ExecuteHandler(mozilla::dom::EventTarget*, nsIDOMEvent*) (/REF-OBJ-DIR/objdir-tb3/dom/xbl/../../dist/include/nsCOMPtr.h:698)
#49: nsXBLEventHandler::HandleEvent(nsIDOMEvent*) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/xbl/nsXBLEventHandler.cpp:52)
#50: mozilla::EventListenerManager::HandleEventSubType(mozilla::EventListenerManager::Listener*, nsIDOMEvent*, mozilla::dom::EventTarget*) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventListenerManager.cpp:976)
#51: mozilla::EventListenerManager::HandleEventInternal(nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent**, mozilla::dom::EventTarget*, nsEventStatus*) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventListenerManager.cpp:1122)
#52: mozilla::EventTargetChainItem::HandleEventTargetChain(nsTArray<mozilla::EventTargetChainItem>&, mozilla::EventChainPostVisitor&, mozilla::EventDispatchingCallback*, mozilla::ELMCreationDetector&) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventDispatcher.cpp:210)
#53: mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsCOMArray<mozilla::dom::EventTarget>*) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventDispatcher.cpp:638)
#54: PresShell::HandleEventInternal(mozilla::WidgetEvent*, nsEventStatus*) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsPresShell.cpp:8252)
#55: PresShell::HandlePositionedEvent(nsIFrame*, mozilla::WidgetGUIEvent*, nsEventStatus*) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsPresShell.cpp:7958)
#56: PresShell::HandleEvent(nsIFrame*, mozilla::WidgetGUIEvent*, bool, nsEventStatus*) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsPresShell.cpp:7758)
#57: nsViewManager::DispatchEvent(mozilla::WidgetGUIEvent*, nsView*, nsEventStatus*) (/REF-OBJ-DIR/objdir-tb3/view/../dist/include/nsCOMPtr.h:390)
#58: nsView::HandleEvent(mozilla::WidgetGUIEvent*, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/view/nsViewManager.h:32)
#59: nsWindow::DispatchEvent(mozilla::WidgetGUIEvent*, nsEventStatus&) (/REF-COMM-CENTRAL/comm-central/mozilla/widget/gtk/nsWindow.cpp:479)
#60: nsWindow::OnButtonPressEvent(_GdkEventButton*) (/REF-COMM-CENTRAL/comm-central/mozilla/widget/gtk/nsWindow.cpp:2756)
#61: button_press_event_cb(_GtkWidget*, _GdkEventButton*) (/REF-COMM-CENTRAL/comm-central/mozilla/widget/gtk/nsWindow.cpp:5315)
#62: gtk_marshal_VOID__UINT_STRING (/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0)
#63: g_closure_invoke (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0)
#64: g_signal_handler_disconnect (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0)
#65: g_signal_emit_valist (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0)
#66: g_signal_emit (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0)
#67: gtk_widget_translate_coordinates (/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0)
#68: gtk_propagate_event (/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0)
#69: gtk_main_do_event (/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0)
#70: gdk_event_get_graphics_expose (/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0)
#71: g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0)
#72: g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0)
#73: g_main_context_iteration (/lib/x86_64-linux-gnu/libglib-2.0.so.0)
#74: nsAppShell::ProcessNextNativeEvent(bool) (/REF-COMM-CENTRAL/comm-central/mozilla/widget/gtk/nsAppShell.cpp:156)
#75: nsBaseAppShell::DoProcessNextNativeEvent(bool, unsigned int) (/REF-COMM-CENTRAL/comm-central/mozilla/widget/nsBaseAppShell.cpp:140)
#76: nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool, unsigned int) (/REF-COMM-CENTRAL/comm-central/mozilla/widget/nsBaseAppShell.cpp:298)
#77: nsThread::ProcessNextEvent(bool, bool*) (/REF-OBJ-DIR/objdir-tb3/xpcom/threads/../../dist/include/nsTArray.h:330)
#78: NS_ProcessNextEvent(nsIThread*, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/nsThreadUtils.cpp:265)
#79: mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (/REF-COMM-CENTRAL/comm-central/mozilla/ipc/glue/MessagePump.cpp:140)
#80: MessageLoop::RunInternal() (/REF-COMM-CENTRAL/comm-central/mozilla/ipc/chromium/src/base/message_loop.cc:234)
#81: MessageLoop::Run() (/REF-COMM-CENTRAL/comm-central/mozilla/ipc/chromium/src/base/message_loop.cc:508)
#82: nsBaseAppShell::Run() (/REF-COMM-CENTRAL/comm-central/mozilla/widget/nsBaseAppShell.cpp:166)
#83: nsAppStartup::Run() (/REF-COMM-CENTRAL/comm-central/mozilla/toolkit/components/startup/nsAppStartup.cpp:282)
#84: XREMain::XRE_mainRun() (/REF-COMM-CENTRAL/comm-central/mozilla/toolkit/xre/nsAppRunner.cpp:4154)
#85: XREMain::XRE_main(int, char**, nsXREAppData const*) (/REF-COMM-CENTRAL/comm-central/mozilla/toolkit/xre/nsAppRunner.cpp:4229)
#86: XRE_main (/REF-COMM-CENTRAL/comm-central/mozilla/toolkit/xre/nsAppRunner.cpp:4449)
#87: do_main(int, char**, nsIFile*) (/REF-COMM-CENTRAL/comm-central/mail/app/nsMailApp.cpp:188)
#88: main (/REF-COMM-CENTRAL/comm-central/mail/app/nsMailApp.cpp:400)
#89: __libc_start_main (/home/aurel32/glibc/glibc-2.19/csu/libc-start.c:321)
#90: _start (/REF-OBJ-DIR/objdir-tb3/dist/bin/thunderbird)
#91: ??? (???:???)
Sleeping for 300 seconds.
Type 'gdb /REF-OBJ-DIR/objdir-tb3/dist/bin/thunderbird 22110' to attach your debugger to this thread.
Done sleeping...
ishikawa@ip030:/REF-COMM-CENTRAL/comm-central$
xref bug 1099587

Comment 3

4 years ago
From ludo's crash report

This bug was filed from the Socorro interface and is 
report bp-525c5ba5-0e11-4ef4-bbab-7b2172141214.
=============================================================
 0 	XUL 	nsIOService::NewChannelFromURIWithProxyFlags2(nsIURI*, nsIURI*, unsigned int, nsIDOMNode*, nsIPrincipal*, nsIPrincipal*, unsigned int, unsigned int, nsIChannel**) 	/builds/slave/tb-c-cen-osx64-ntly-0000000000/build/objdir-tb/x86_64/dist/include/nsILoadInfo.h:96
1 	XUL 	nsIOService::NewChannelFromURI2(nsIURI*, nsIDOMNode*, nsIPrincipal*, nsIPrincipal*, unsigned int, unsigned int, nsIChannel**) 	netwerk/base/src/nsIOService.cpp
2 	XUL 	nsImapProtocol::SetupWithUrl(nsIURI*, nsISupports*) 	/builds/slave/tb-c-cen-osx64-ntly-0000000000/build/objdir-tb/x86_64/dist/include/nsNetUtil.h:289
3 	XUL 	nsImapProtocol::LoadImapUrl(nsIURI*, nsISupports*) 	/builds/slave/tb-c-cen-osx64-ntly-0000000000/build/mailnews/imap/src/nsImapProtocol.cpp:2138
4 	XUL 	nsImapIncomingServer::GetImapConnectionAndLoadUrl(nsIImapUrl*, nsISupports*) 	/builds/slave/tb-c-cen-osx64-ntly-0000000000/build/mailnews/imap/src/nsImapIncomingServer.cpp:443
5 	XUL 	nsImapService::GetImapConnectionAndLoadUrl(nsIImapUrl*, nsISupports*, nsIURI**) 	/builds/slave/tb-c-cen-osx64-ntly-0000000000/build/mailnews/imap/src/nsImapService.cpp:2224
6 	XUL 	nsImapService::SelectFolder(nsIMsgFolder*, nsIUrlListener*, nsIMsgWindow*, nsIURI**) 	/builds/slave/tb-c-cen-osx64-ntly-0000000000/build/mailnews/imap/src/nsImapService.cpp:220
7 	XUL 	nsImapMailFolder::UpdateFolderWithListener(nsIMsgWindow*, nsIUrlListener*) 	/builds/slave/tb-c-cen-osx64-ntly-0000000000/build/mailnews/imap/src/nsImapMailFolder.cpp:811
8 	XUL 	NS_InvokeByIndex 	xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp
9 	XUL 	XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) 	js/xpconnect/src/XPCWrappedNative.cpp
10 	XUL 	XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp
11 	XUL 	js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) 	js/src/jscntxtinlines.h
12 	XUL 	Interpret 	js/src/vm/Interpreter.cpp
13 	XUL 	js::RunScript(JSContext*, js::RunState&) 	js/src/vm/Interpreter.cpp
14 	XUL 	js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct)
Crash Signature: [@ nsIOService::NewChannelFromURIWithProxyFlags2(nsIURI*, nsIURI*, unsigned int, nsIDOMNode*, nsIPrincipal*, nsIPrincipal*, unsigned int, unsigned int, nsIChannel**)]
Component: Untriaged → Security
Depends on: 1099587
Keywords: crash
OS: Linux → All
Whiteboard: [startup crash]

Updated

4 years ago
Duplicate of this bug: 1111341
With a backout of https://hg.mozilla.org/mozilla-central/rev/9f78c3062ad9 TB is working again for me. Confirmed also from German NG for Linux SM.

Comment 7

4 years ago
I can confirm that exactly this problem exists in Linux x86_64 Seamonkey. The nightly built on 11th December 2014 (the one I am using to post this) works, later ones do not.

Comment 8

4 years ago
(In reply to David Edwards from comment #7)
> I can confirm that exactly this problem exists in Linux x86_64 Seamonkey.
> The nightly built on 11th December 2014 (the one I am using to post this)
> works, later ones do not.

And the backout mentioned in Comment 7 helps for SM Trunk Linux x86_64.

Comment 9

4 years ago
> And the backout mentioned in Comment 7 helps for SM Trunk Linux x86_64.

Typo. Comment 6.
Here is what you have to do, you have to set a loadInfo on the channel within each NewChannel2 implementation. I think Bug 1088497 covers all the ::NewChannel2 implementation. You can base your implementation on the other ::NewChannel2() implementation covered in Bug 1087442.
Component: Security → Backend
Keywords: dogfood
Product: Thunderbird → MailNews Core
Depends on: 1087442
(Reporter)

Comment 11

4 years ago
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #10)
> Here is what you have to do, you have to set a loadInfo on the channel
> within each NewChannel2 implementation. I think Bug 1088497 covers all the
> ::NewChannel2 implementation. You can base your implementation on the other
> ::NewChannel2() implementation covered in Bug 1087442.

Isn't the problem a too strict a check on line 700 since TB seems to pass
|nullptr| for loadInfo in many NewChannel2() usage?

  698	      nsCOMPtr<nsILoadInfo> loadInfo;
  699	      (*result)->GetLoadInfo(getter_AddRefs(loadInfo));
  700	      MOZ_ASSERT(loadInfo);
  701	
  702	      // If we're sandboxed, make sure to clear any owner the channel
  703	      // might already have.
  704	      if (loadInfo->GetLoadingSandboxed()) {
  705	        (*result)->SetOwner(nullptr);
  706	      }

Maybe we can comment out 700 and
surround 704 - 706 with
 if (loadInfo ) {
   ...
 }

???

Updated

4 years ago
Duplicate of this bug: 1111603

Updated

4 years ago
Blocks: 1087442
No longer depends on: 1087442
Keywords: regression
status-seamonkey2.34: --- → affected
status-thunderbird37: --- → affected
tracking-seamonkey2.34: --- → ?
tracking-thunderbird37: --- → ?
Version: unspecified → Trunk

Comment 13

4 years ago
(In reply to ISHIKAWA, Chiaki from comment #11)

> Maybe we can comment out 700 and
> surround 704 - 706 with
>  if (loadInfo ) {
>    ...
>  }
> 
> ???

That works for my SM-Trunk Linux x86_64.

Comment 14

4 years ago
So just applying patches in bug 1099587 is not enough? Is the loadinfo stuff new?

Comment 15

4 years ago
No, doesn't me. I get crash just by attempting to show a message in a folder:
Assertion failure: loadInfo, at mozilla/netwerk/base/src/nsIOService.cpp:700

Comment 16

4 years ago
Created attachment 8536764 [details] [diff] [review]
patch_loadinfo

(In reply to :aceman from comment #15)
> No, doesn't me. I get crash just by attempting to show a message in a folder:
> Assertion failure: loadInfo, at mozilla/netwerk/base/src/nsIOService.cpp:700

Here is my patch based on Comment 11. I am using a SM compiled with this patch since some hours now without problems.

But: it is not a hg-patch. ;)
Created attachment 8537074 [details] [diff] [review]
patch_loadinfo (rewritten in hg-git style for mozilla-central)

This is (IIUC) the equivalent hg-git style patch.

As written here, it should be applied to mozilla-central (a clone of which is at ./mozilla in every working comm-central clone) and, if deemed correct, reviewed by an owner or peer of the Network module.

Hartmut, what do you think of it?
Attachment #8536764 - Attachment is obsolete: true
Attachment #8537074 - Flags: feedback?(h.figge)

Comment 18

4 years ago
Created attachment 8537136 [details] [diff] [review]
attach_loadinfo

(In reply to Tony Mechelynck [:tonymec] from comment #17)
> Created attachment 8537074 [details] [diff] [review]
> patch_loadinfo (rewritten in hg-git style for mozilla-central)
>
> Hartmut, what do you think of it?

After manually correcting loadinfo to loadInfo my new build succeeded and worked without crash.
Attachment #8537074 - Attachment is obsolete: true
Attachment #8537074 - Flags: feedback?(h.figge)
(In reply to Hartmut Figge from comment #18)
> After manually correcting loadinfo to loadInfo my new build succeeded and
> worked without crash.

Oops, that's what I got for patching by hand without double- and triple-checking.

I suppose the next step is to get the patch reviewed; maybe also move the bug to Core::Networking or one of its sub-components.

The Network owners and peers are listed at https://wiki.mozilla.org/Modules/Core#Necko : select one, set review? on your attachment with his handle, and wait for an answer.

Updated

4 years ago
Attachment #8537136 - Flags: review?(cbiesinger)
Comment on attachment 8537136 [details] [diff] [review]
attach_loadinfo

I don't think biesi is very active these days let's ask the module owner.
Attachment #8537136 - Flags: review?(cbiesinger) → review?(mcmanus)
Comment on attachment 8537136 [details] [diff] [review]
attach_loadinfo

Review of attachment 8537136 [details] [diff] [review]:
-----------------------------------------------------------------

As I understand things, the proposed patch is pretty much the opposite of the intention of 1087442 - but I've delegated the review to Christoph to make sure.

I think comment 10 contains the necessary info about resolution
Attachment #8537136 - Flags: review?(mcmanus) → review?(ckerschbaumer)
Comment on attachment 8537136 [details] [diff] [review]
attach_loadinfo

Review of attachment 8537136 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to Patrick McManus [:mcmanus] from comment #21)
> Comment on attachment 8537136 [details] [diff] [review]
> attach_loadinfo
> 
> Review of attachment 8537136 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> As I understand things, the proposed patch is pretty much the opposite of
> the intention of 1087442 - but I've delegated the review to Christoph to
> make sure.
> 
> I think comment 10 contains the necessary info about resolution

As Patrick explains correctly, we do want a LoadInfo attached to all channels. That's the intention of that MOZ_ASSERT(). The right way to fix the problem is covered by Comment 10. I am happy to guide you and provide feedback. It shouldn't be that hard, there are only a few ::NewChannel2() implementations where you basically just need to call setLoadInfo().
Attachment #8537136 - Flags: review?(ckerschbaumer) → review-
(Assignee)

Comment 23

4 years ago
Created attachment 8537542 [details] [diff] [review]
bug1111304.patch

I am not sure nullprincipal is suitable for nsMailboxService.

https://treeherder.mozilla.org/ui/#/jobs?repo=try-comm-central&revision=41cc25e2fc6d
Attachment #8537136 - Attachment is obsolete: true
Attachment #8537542 - Flags: review?(mozilla)
Comment on attachment 8537542 [details] [diff] [review]
bug1111304.patch

Review of attachment 8537542 [details] [diff] [review]:
-----------------------------------------------------------------

::: mailnews/imap/src/nsImapService.cpp
@@ +2651,5 @@
>    // a mock imap channel....
>    nsCOMPtr<nsIImapMockChannel> channel = do_CreateInstance(kCImapMockChannel, &rv);
>    NS_ENSURE_SUCCESS(rv, rv);
>    channel->SetURI(aURI);
> +

::NewChannel2() should already have 'aLoadInfo' argument, right? see
http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapService.cpp#2654

You just have to set it on the newly created channel.
channel->SetLoadInfo(aLoadInfo);
Attachment #8537542 - Flags: review?(mozilla) → review-
(Assignee)

Comment 25

4 years ago
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #24)
> Comment on attachment 8537542 [details] [diff] [review]
> bug1111304.patch
> 
> Review of attachment 8537542 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: mailnews/imap/src/nsImapService.cpp
> @@ +2651,5 @@
> >    // a mock imap channel....
> >    nsCOMPtr<nsIImapMockChannel> channel = do_CreateInstance(kCImapMockChannel, &rv);
> >    NS_ENSURE_SUCCESS(rv, rv);
> >    channel->SetURI(aURI);
> > +
> 
> ::NewChannel2() should already have 'aLoadInfo' argument, right? see
> http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapService.
> cpp#2654
> 
> You just have to set it on the newly created channel.
> channel->SetLoadInfo(aLoadInfo);

You mean we should fix nsImapService::NewChannel2 instead of nsImapService::NewChannel?
nsImapService::NewChannel passes a nullptr to NewChannel2 like nsGIOProtocolHandler does.
Referred to attachment 8534697 [details] [diff] [review] in bug 1087442.
The code slightly changed since I pushed another changeset last night. Anyway, this is the relevant part now:
http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsIOService.cpp#669

The assertion is only triggered if ::NewChannelFromURIWIthProxyFlags2() can call NewChannel2() on the protocolHandler. If so, then we are asserting that the returned channel indeed has a LoadInfo attached. All you have to do is set the LoadInfo within ::NewChannel2() in all your protocolHandlers. See comment 10 for details. That will fix the problem!
(Assignee)

Comment 28

4 years ago
Comment on attachment 8537565 [details] [diff] [review]
v2

Clearing review request.

I did not understand how to deal nsILoadInfo yet.
Attachment #8537565 - Flags: review?(mozilla)
(Assignee)

Comment 29

4 years ago
Created attachment 8537595 [details] [diff] [review]
v3

I hope I am on the right way.

https://treeherder.mozilla.org/ui/#/jobs?repo=try-comm-central&revision=6a791cc129ee
Attachment #8537565 - Attachment is obsolete: true
Attachment #8537595 - Flags: review?(mozilla)
(Assignee)

Comment 30

4 years ago
(In reply to Hiroyuki Ikezoe (:hiro) from comment #29)
> https://treeherder.mozilla.org/ui/#/jobs?repo=try-comm-
> central&revision=6a791cc129ee

Here is the correct link of the try.
https://treeherder.mozilla.org/ui/#/jobs?repo=try-comm-central&revision=f6c3ffc1e3aa
(Reporter)

Comment 31

4 years ago
I can't still run the debug version of TB from the source tree
refreshed a couple of hours ago.
But this is without Hiro's patch yet.

The reason I wanted to run TB without Hiro's patch was to confirm where the error occurs exactly and why in light of comment 24 and comment 22.
(Comment 10 was too opaque for occasional contributor who just post patches to observed bugs now and then. The last line of comment 24 gave a clue to me in my case.)

But then I noticed in the recent run using the refreshed tree,
I see the following group of errors many times before
I get to hit the crash due to MOZ_ASSERT() when I click on a message subject header in the header summary.

The group of errors is:
[8620] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 289
[8620] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 289
[8620] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp, line 677

That is, I see erros at line 289 of comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp followed by an error at line 677 of  comm-central/mozilla/netwerk/base/src/nsIOService.cpp.

This error group repeated many times (About 30 times) before
I get the crash after clicking on a message summary line.

I will investigate what these errors are and if they are related
to the issue at hand.


From the log of running thundebird (full debug version) from a console.

JavaScript warning: resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/ishikawa/.thunderbird/u1ku1i3y.default/extensions/jid0-edalmuivkozlouyij0lpdx548bc@jetpack.xpi!/bootstrap.js -> resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js -> resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/clipboard.js, line 134: JavaScript 1.7's let blocks are deprecated
[8620] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 289
[8620] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 289
[8620] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp, line 677
[8620] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 289
[8620] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 289
[8620] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp, line 677
[8620] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 289
[8620] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 289
[8620] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp, line 677

       ... many repetitions of errros at line 289 of nsResProtocolHandler.cpp,
       ... and at line 677 on nsIOService.cpp
       
[8620] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 289
[8620] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 289
[8620] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp, line 677
error: geckoprofiler: An exception occurred.
Error: The panel module currently supports only Firefox.  In the future we would like it to support other applications, however.  Please see https://bugzilla.mozilla.org/show_bug.cgi?id=jetpack-panel-apps for more information.
resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/panel.js 12
Traceback (most recent call last):
  File "resource://gre/modules/NetUtil.jsm:123", line 17, in NetUtil_asyncOpen/<.onStopRequest
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/net/url.js:49", line 9, in readAsync/<
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:142", line 32, in resolve
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:36", line 43, in then
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:116", line 34, in resolved
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:142", line 32, in resolve
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:36", line 43, in then
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:116", line 34, in resolved
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:142", line 32, in resolve
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:36", line 43, in then
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:116", line 34, in resolved
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:142", line 32, in resolve
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:36", line 43, in then
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:116", line 34, in resolved
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:142", line 32, in resolve
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:36", line 43, in then
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:116", line 34, in resolved
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:142", line 32, in resolve
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:122", line 12, in then
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:36", line 43, in then
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:116", line 51, in resolved
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:54", line 18, in effort
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:116", line 34, in resolved
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:142", line 32, in resolve
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:36", line 43, in then
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:116", line 51, in resolved
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/core/promise.js:54", line 18, in effort
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/addon/runner.js:91", line 7, in onLocalizationReady
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/addon/runner.js:123", line 19, in run
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js:342", line 10, in main
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js:237", line 5, in load
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js:210", line 19, in evaluate
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/geckoprofiler/lib/main.js:124", line 23, in
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js:328", line 14, in require
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js:237", line 5, in load
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js:210", line 19, in evaluate
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/pathfinder/lib/ui/toolbarbutton.js:11", line 39, in
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js:328", line 14, in require
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js:237", line 5, in load
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js:210", line 19, in evaluate
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/pathfinder/lib/ui/validate.js:4", line 19, in
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js:328", line 14, in require
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js:237", line 5, in load
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js:210", line 19, in evaluate
  File "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/panel.js:12", line 1, in
[8620] WARNING: Subdocument container has no frame: file /REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsDocumentViewer.cpp, line 2505
++DOMWINDOW == 29 (0x5ae40b0) [pid = 8620] [serial = 29] [outer = 0x3116bf0]
Begin mail message delivery.
Abort mail message delivery.
++DOMWINDOW == 30 (0x2b73f90) [pid = 8620] [serial = 30] [outer = 0x3118e30]
Assertion failure: loadInfo, at /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp:687
#01: nsIOService::NewChannelFromURI2(nsIURI*, nsIDOMNode*, nsIPrincipal*, nsIPrincipal*, unsigned int, unsigned int, nsIChannel**) (/REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp:595)
#02: nsDocShell::DoURILoad(nsIURI*, nsIURI*, bool, unsigned int, nsISupports*, char const*, nsAString_internal const&, nsIInputStream*, nsIInputStream*, bool, nsIDocShell**, nsIRequest**, bool, bool, bool, nsAString_internal const&, nsIURI*, unsigned int) (/REF-OBJ-DIR/objdir-tb3/docshell/base/../../dist/include/nsCOMPtr.h:686)
#03: nsDocShell::InternalLoad(nsIURI*, nsIURI*, unsigned int, nsISupports*, unsigned int, char16_t const*, char const*, nsAString_internal const&, nsIInputStream*, nsIInputStream*, unsigned int, nsISHEntry*, bool, nsAString_internal const&, nsIDocShell*, nsIURI*, nsIDocShell**, nsIRequest**) (/REF-COMM-CENTRAL/comm-central/mozilla/docshell/base/nsDocShell.cpp:10143)
#04: nsDocShell::LoadURI(nsIURI*, nsIDocShellLoadInfo*, unsigned int, bool) [clone .part.322] (/REF-COMM-CENTRAL/comm-central/mozilla/docshell/base/nsDocShell.cpp:1633)
#05: nsMailboxService::FetchMessage(char const*, nsISupports*, nsIMsgWindow*, nsIUrlListener*, char const*, int, char const*, nsIURI**) (/REF-OBJ-DIR/objdir-tb3/mailnews/local/src/../../../dist/include/nsCOMPtr.h:390)
#06: nsMailboxService::DisplayMessage(char const*, nsISupports*, nsIMsgWindow*, nsIUrlListener*, char const*, nsIURI**) (/REF-COMM-CENTRAL/comm-central/mailnews/local/src/nsMailboxService.cpp:275)
#07: nsMessenger::OpenURL(nsACString_internal const&) (/REF-OBJ-DIR/objdir-tb3/mailnews/base/src/../../../dist/include/nsTSubstring.h:95)
#08: nsMsgDBView::LoadMessageByViewIndex(unsigned int) (/REF-OBJ-DIR/objdir-tb3/mailnews/base/src/../../../dist/include/nsTArray.h:330)
#09: nsMsgGroupView::LoadMessageByViewIndex(unsigned int) (/REF-COMM-CENTRAL/comm-central/mailnews/base/src/nsMsgGroupView.cpp:900)
#10: nsMsgDBView::SelectionChanged() (/REF-COMM-CENTRAL/comm-central/mailnews/base/src/nsMsgDBView.cpp:1190)
#11: NS_InvokeByIndex (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/reflect/xptc

     ... the rest is omitted ...

TIA
(Reporter)

Comment 32

4 years ago
Sorry the group of error lines that I noticed have nothing to do
with the issue at hand, but rather with the failure to
load gecko profiler, it seems.

I got the following output after instrumenting
nsResProtocolHandler::ResolveURI(nsIURI *uri, nsACString &result).

See the excerpt from the log.

Note "(debug)" lines.
It seems thunderbird does not grok
resource://gre/modules/...pathnames WITH :NNN at the end... properly.

That is, the line number ":NNN" at the end of a path is not understood
when jetpack (profiler) package is loaded into TB.

Why jetpack wants to pass paths in the form of filename:NNN in the
first place, I have no idea.

Excerpt from the log: (Sometimes people ought to take a look at the
log of test runs of DEBUG build of TB or FF and see how many error
and warning lines clutter the output!)

JavaScript strict warning: chrome://messenger/content/tabmail.xml, line 352: ReferenceError: reference to undefined property aTabType.panelId
JavaScript strict warning: , line 0: TypeError: "Services" is read-only
[17525] WARNING: Could not get disk status from nsIDiskSpaceWatcher: file /REF-COMM-CENTRAL/comm-central/mozilla/uriloader/prefetch/nsOfflineCacheUpdateService.cpp, line 321
GetDiskSpaceAvailable returned: 3071197184 bytes
++DOMWINDOW == 28 (0x5ffe0b0) [pid = 17525] [serial = 28] [outer = 0x35efbb0]
JavaScript strict warning: resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/ishikawa/.thunderbird/u1ku1i3y.default/extensions/jid0-edalmuivkozlouyij0lpdx548bc@jetpack.xpi!/bootstrap.js -> resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js -> resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/geckoprofiler/lib/main.js, line 2002: SyntaxError: in strict mode code, functions may be declared only at top level or immediately within another function
JavaScript strict warning: resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/ishikawa/.thunderbird/u1ku1i3y.default/extensions/jid0-edalmuivkozlouyij0lpdx548bc@jetpack.xpi!/bootstrap.js -> resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js -> resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/geckoprofiler/lib/prefs.js, line 54: TypeError: variable value redeclares argument
JavaScript strict warning: resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/ishikawa/.thunderbird/u1ku1i3y.default/extensions/jid0-edalmuivkozlouyij0lpdx548bc@jetpack.xpi!/bootstrap.js -> resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js -> resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/geckoprofiler/lib/prefs.js, line 74: TypeError: variable value redeclares argument
JavaScript strict warning: resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/ishikawa/.thunderbird/u1ku1i3y.default/extensions/jid0-edalmuivkozlouyij0lpdx548bc@jetpack.xpi!/bootstrap.js -> resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js -> resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/geckoprofiler/lib/prefs.js, line 81: TypeError: variable value redeclares argument
JavaScript warning: resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/ishikawa/.thunderbird/u1ku1i3y.default/extensions/jid0-edalmuivkozlouyij0lpdx548bc@jetpack.xpi!/bootstrap.js -> resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js -> resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/clipboard.js, line 123: JavaScript 1.7's let blocks are deprecated
JavaScript warning: resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/ishikawa/.thunderbird/u1ku1i3y.default/extensions/jid0-edalmuivkozlouyij0lpdx548bc@jetpack.xpi!/bootstrap.js -> resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/toolkit/loader.js -> resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/clipboard.js, line 134: JavaScript 1.7's let blocks are deprecated
(debug) unescapedPath.FindChar(':') was not -1. host=gre, path=/modules/NetUtil.jsm:123, unescapedPath=/modules/NetUtil.jsm:123
[17525] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 289
(debug) handler->NewChannel2 failed in nsIOService::NewChannelFromURIWithProxyFlagsInternal
(debug) unescapedPath.FindChar(':') was not -1. host=gre, path=/modules/NetUtil.jsm:123, unescapedPath=/modules/NetUtil.jsm:123
[17525] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 289
(debug) handler->NewChannel also  failed in nsIOService::NewChannelFromURIWithProxyFlagsInternal
[17525] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp, line 699
(debug) unescapedPath.FindChar(':') was not -1. host=jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack, path=/addon-sdk/lib/sdk/net/url.js:49, unescapedPath=/addon-sdk/lib/sdk/net/url.js:49
[17525] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 289
(debug) handler->NewChannel2 failed in nsIOService::NewChannelFromURIWithProxyFlagsInternal
(debug) unescapedPath.FindChar(':') was not -1. host=jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack, path=/addon-sdk/lib/sdk/net/url.js:49, unescapedPath=/addon-sdk/lib/sdk/net/url.js:49
[17525] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 289
(debug) handler->NewChannel also  failed in nsIOService::NewChannelFromURIWithProxyFlagsInternal
[17525] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp, line 699

--- end of excerpt

So, I am sorry that the particular bugs I noticed is not for this
bugzilla, but probably for Bug 494238,
specifically the issue with using profiler with TB, see the following
comment there.
https://bugzilla.mozilla.org/show_bug.cgi?id=494238#c45

At the same time, I have to report a surprising performance issue (or
maybe not that surprising to seasoned developers) that the function
nsIOService::NewChannelFromURIWithProxyFlagsInternal where
MOZ_ASSERT() is placed, is called more than 2600 times in my TB setup
before the summary window is filled and I can hit the subject of a
particular message and observe the crash.

Of course, it seems that this function is invoked for every JS file
load, etc., but still, isn't 2600+ calls a little excessive
considering all the processing this function and related functions do?
(No wonder sometimes I feel TB rather slowish...)

TIA

PS: BTW, I finally figured out the cause of the issue. I will post it
in the next comment.
(Reporter)

Comment 33

4 years ago
Created attachment 8537972 [details] [diff] [review]
A bug in nsResProtocolHandler.cpp ?

TB is so important in my workflow, I could not get this bug
pending for so long to endanger the future release of TB in the next
several months. So I inserted many fprintf() to figure out what was
causing the issue and found this.

Basically, I inserted fprintf() and dumped interesting values along
the functions mentioned in the stack trace.

First-Aid Remedy:

In 
nsIOService::NewChannelFromURIWithProxyFlagsInternal
(File: comm-central/mozilla/netwerk/base/src/nsIOService.cpp ),
immediately after the successful run of  either one of the following
lines that would create a new channel after success,
 pph->NewProxiedChannel2(aURI, nullptr, aProxyFlags, aProxyURI,...
 pph->NewProxiedChannel(aURI, nullptr, aProxyFlags, aProxyURI, ...
 handler->NewChannel2(aURI, aLoadInfo, result);
 handler->NewChannel(aURI, result);

if (*result)->SetLoadInfo(aLoadInfo) is called to set nsILoadInfo
explicitly, MOZ_ASSERT() does not assert. (This is obvious.)

So it is indeed true that some functions above forget to set nsILoadInfo.
I narrowed down the culprit by checking
the value of tmploadInfo
as in
           nsCOMPtr<nsILoadInfo> tmploadInfo;
            (*result)->GetLoadInfo(getter_AddRefs(tmploadInfo));

immediately after the successful run of of the above four creation of channels.
Then I found out that the 
call to handler->NewChannel2 caused the failure to return
non-null tmploadInfo, thus blows up TB when I clicked on the
subject line in the summary window.

So incorrect implementation of NewChannel2 is the culprit.

There are only a few NewChannel2 implementation in C-C
portion of the code.
From mxr.mozilla.org, I found NewChannel2 in C-C as follows.

Defined as a function in:

    mailnews/addrbook/src/nsAddbookProtocolHandler.cpp (View Hg log or Hg annotations)
        line 123, as member of class nsAddbookProtocolHandler -- nsAddbookProtocolHandler::NewChannel2(nsIURI *aURI, 
    mailnews/base/src/nsCidProtocolHandler.cpp (View Hg log or Hg annotations)
        line 62, as member of class nsCidProtocolHandler -- NS_IMETHODIMP nsCidProtocolHandler::NewChannel2(nsIURI *aURI, 
    mailnews/news/src/nsNntpService.cpp (View Hg log or Hg annotations)
        line 1238, as member of class nsNntpService -- NS_IMETHODIMP nsNntpService::NewChannel2(nsIURI *aURI, 
    mozilla/chrome/nsChromeProtocolHandler.cpp (View Hg log or Hg annotations)
        line 102, as member of class nsChromeProtocolHandler -- nsChromeProtocolHandler::NewChannel2(nsIURI* aURI, 

	... I am omitting other mozilla/* files (M-C portion)

    calendar/base/src/calProtocolHandler.js (View Hg log or Hg annotations)
        line 45 -- newChannel2: function cph_newChannel2(aUri, aLoadInfo) 
    chat/components/src/smileProtocolHandler.js (View Hg log or Hg annotations)
        line 31 -- }, 
    ldap/xpcom/src/nsLDAPProtocolHandler.js (View Hg log or Hg annotations)
        line 36 -- newChannel2: function (aURI, aLoadInfo) { 

	... one mozilla/* file is omitted

    suite/common/src/nsGopherProtocolStubHandler.js (View Hg log or Hg annotations)
        line 48 -- newChannel2: function GP_newChannel2(inputURI, loadinfo) { 
    suite/feeds/src/FeedConverter.js (View Hg log or Hg annotations)
        line 516 -- newChannel2: function newChannel(aUri, aLoadinfo) { 

*HOWEVER*(!), 
I am seeing a problem of TB using SMTP and POP3: not IMAP and not
NNTP. I am not using Calendar, nor ldap.
I am seeing the problem when I click on the subject in subject summary
window, so address book is not related.

So NewChannel2 in C-C is unlikely to be the cause of the issue.

Then what? M-C portion needs to be investigated.

As I check mozilla/* files (M-C), it occurred to me immediately that
my TB was calling functions in
comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, 
specifically, nsResProtocolHandler::ResolveURI(nsIURI *uri, nsACString &result)
as in my previous post comment 31

So naturally I looked at NewChannel2 in this file.
Bingo!

In this file,
nsResProtocolHandler::NewChannel2(nsIURI* uri, ...) 
fails to set nsILoadInfo by calling SetLoadInfo just
before returning.

    (*result)->SetLoadInfo(aLoadInfo);

By calling this just before returning,
at least, I can get past the former crash when
I click on the subject of a message in the summary line.

Attached is a simple diff form: it contains extra debug statements for
ResolveURI() but it is inside #if DEBUG/#endif and so should not be a
problem for non-debug build.  If others apply this patch and their TB
works, then probably this is the issue after all.  I will create a
formal hg diff patch then.

After writing all this, I realize that there seems to be at least one
other case of NewChannel2 which does not set nsILoadInfo and the
problem is saved by the forced setting of it as in the "First-Aid
Remedy" in my current copy of TB binary.  Maybe the symptom may differ
from one user to the other.  I want to hear where a NEW crash occurs
after the patch on others machines. Then we can nail down the other
problem (one by one).

TIA
Comment on attachment 8537595 [details] [diff] [review]
v3

Review of attachment 8537595 [details] [diff] [review]:
-----------------------------------------------------------------

That looks better, but I am not the right person to review this patch. I honestly don't know who the right person to ask is.
Attachment #8537595 - Flags: review?(mozilla)
Comment on attachment 8537595 [details] [diff] [review]
v3

Review of attachment 8537595 [details] [diff] [review]:
-----------------------------------------------------------------

I'm not sure about the changes to nsSmtpService.cpp and nsAddbookProtocolHandler.cpp, since I don't know what the ramifications of different calls to NS_NewChannel* are. I would have to confer with some necko people to adequately answer that.

::: mailnews/imap/src/nsImapService.cpp
@@ +2655,5 @@
> +
> +  rv = channel->SetLoadInfo(aLoadInfo);
> +  if (NS_FAILED(rv)) {
> +    return rv;
> +  }

Nit: NS_ENSURE_SUCCESS(rv, rv);
(× multiple places)

::: mailnews/local/src/nsMailboxService.cpp
@@ +597,5 @@
>        NS_ENSURE_SUCCESS(rv, rv);
>        return handler->NewChannel(pop3Uri, _retval);
>      }
>    }
>    nsMailboxProtocol * protocol = new nsMailboxProtocol(aURI);

If you're already being this invasive, it makes sense to replace this with nsRefPtr<nsMailboxProtocol> and not do manual deletion on failure, especially seeing as your proposed code would leak in certain error cases.

::: mailnews/news/src/nsNntpService.cpp
@@ +1249,1 @@
>    return server->GetNntpChannel(aURI, nullptr, _retval);

I do believe you need to actually delete this line of code if you're expecting changes to actually take effect.

@@ +1256,5 @@
> +  if (NS_FAILED(rv)) {
> +    return rv;
> +  }
> +
> +  NS_IF_ADDREF(*_retval = channel);

channel.forget(_retval); is the proper way to call this these days.
Attachment #8537595 - Flags: review-
(Assignee)

Comment 36

4 years ago
Created attachment 8538097 [details] [diff] [review]
v4

Fixed all pointed out in comment #35.
Attachment #8537595 - Attachment is obsolete: true
Attachment #8538097 - Flags: review?(Pidgeot18)
(Assignee)

Comment 38

4 years ago
Comment on attachment 8538097 [details] [diff] [review]
v4

Christoph, could you please check the change of nsAddbookProtocolHandler.cpp and nsSmtpService.cpp?
Attachment #8538097 - Flags: review?(mozilla)
Comment on attachment 8538097 [details] [diff] [review]
v4

Review of attachment 8538097 [details] [diff] [review]:
-----------------------------------------------------------------

As I said, I am not the right reviewer, but I can provide feedback. Let me know if you have more questions!

::: mailnews/addrbook/src/nsAddbookProtocolHandler.cpp
@@ +105,5 @@
> +                                            NS_LITERAL_CSTRING("text/xml"),
> +                                            EmptyCString(),
> +                                            aLoadInfo);
> +  }
> +

Since you are not using 'channel' in case you have aLoadInfo, you could declare it after this return statement.

::: mailnews/local/src/nsMailboxService.cpp
@@ +594,5 @@
>        nsCOMPtr <nsIURI> pop3Uri;
>  
>        rv = handler->NewURI(spec, "" /* ignored */, aURI, getter_AddRefs(pop3Uri));
>        NS_ENSURE_SUCCESS(rv, rv);
>        return handler->NewChannel(pop3Uri, _retval);

return handler->NewChannel2(pop3Uri, aLoadInfo, _retval);

@@ +613,1 @@
>  }

I think you can leave the rest unchanged, just call NewChannel2 above as explained.

::: mailnews/local/src/nsPop3Service.cpp
@@ +516,5 @@
>    NS_ENSURE_SUCCESS(rv, rv);
>  
> +  rv = protocol->SetLoadInfo(aLoadInfo);
> +  NS_ENSURE_SUCCESS(rv, rv);
> +

Remove that part.

@@ +521,2 @@
>    protocol->SetUsername(realUserName.get());
>  

here you have to do something like:
_retval = do_QueryInterface(protocol);
(*_retval)->SetLoadInfo(aLoadInfo);
return NS_OK;
Attachment #8538097 - Flags: review?(mozilla) → feedback+
Comment on attachment 8538097 [details] [diff] [review]
v4

Review of attachment 8538097 [details] [diff] [review]:
-----------------------------------------------------------------

Asides from needing to add the ->NewChannel2 call as ckerschb caught, and a minor nit or two, this patch looks essentially complete. I still want to do a few tests to see if anything is missing first, though.

::: mailnews/local/src/nsMailboxService.cpp
@@ +594,5 @@
>        nsCOMPtr <nsIURI> pop3Uri;
>  
>        rv = handler->NewURI(spec, "" /* ignored */, aURI, getter_AddRefs(pop3Uri));
>        NS_ENSURE_SUCCESS(rv, rv);
>        return handler->NewChannel(pop3Uri, _retval);

Yes, this does need to be done, thank you for catching this. (I imagine this case isn't hit in tests).

@@ +597,5 @@
>        NS_ENSURE_SUCCESS(rv, rv);
>        return handler->NewChannel(pop3Uri, _retval);
>      }
>    }
> +  nsRefPtr<nsMailboxProtocol> protocol = new nsMailboxProtocol(aURI);

Nit: add a new line after the close brace.

::: mailnews/local/src/nsPop3Service.cpp
@@ +521,2 @@
>    protocol->SetUsername(realUserName.get());
>  

Since the protocol is itself a channel, the changes already in this patch are sufficient, there's no need to do the more complicated stuff that ckerschb suggests.
(Reporter)

Comment 41

4 years ago
(In reply to ISHIKAWA, Chiaki from comment #33)
> Created attachment 8537972 [details] [diff] [review]
> A bug in nsResProtocolHandler.cpp ?
> 
> ...

> After writing all this, I realize that there seems to be at least one
> other case of NewChannel2 which does not set nsILoadInfo and the
> problem is saved by the forced setting of it as in the "First-Aid
> Remedy" in my current copy of TB binary.  Maybe the symptom may differ
> from one user to the other.  I want to hear where a NEW crash occurs
> after the patch on others machines. Then we can nail down the other
> problem (one by one).
> 
> TIA

I found out that the added problem is
that loadinfo being passed to 
nsResProtocolHandler::NewChannel2(nsIURI* uri, ...) 
is null.

The problem of NewChannel2() getting called with null {nullptr} 
manifested in the above scenario. Basically
when the call is added in
nsResProtocolHandler::NewChannel2(nsIURI* uri, ...) 
for setting loadinfo as

    (*result)->SetLoadInfo(aLoadInfo);

aLoadInfo there is null and so we end up setting useless null value, which again
was causing MOZ_ASSERT() to blow up.

I hope the patch of Hiro reviewed here replaces the (implicit) calls to NewChannel to NewChannel2 with proper loadinfo being passed.

That said, I think the failure of nsResProtocolHandler to set loadinfo seems to be a genuine bug.
Where should I report it?
Does Christopher have an idea where to report this?

TIA

Comment 42

4 years ago
great to see progress on this.
note, we have >1,000 crash per week on daily, which is exceptionally high even for a topcrash. We surely want to have this fixed before branching for earlybird.
Keywords: topcrash-thunderbird
IIUC, to read one's mail with Thunderbird-Daily or SeaMonkey-trunk it is (temporarily) necessary to stay with the following "last good" nightlies:

ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2014/12/2014-12-12-03-02-03-comm-central (cf. "first bad was yesterday" in comment #0)
ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2014/12/2014-12-13-00-30-01-comm-central-trunk (cf. "first bad" in dupe bug 1111603 comment #0)

No hard feeling, guys, I know you're doing your best.

For SeaMonkey, of course, the latest builds are still good enough when using only the browser and/or ChatZilla but not MailNews.
Erratum for comment #43: the correct "last good" nightly folder for SeaMonkey is

ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2014/12/2014-12-12-00-30-01-comm-central-trunk

not one day later as stated.

Apparently I let the 13th come and go either without getting mail or without upgrading to the next nightly.
(Assignee)

Comment 45

4 years ago
Created attachment 8538451 [details] [diff] [review]
An xpcshell test that load imap url does not cause crash.

I am trying to write another test for the url which has "uidl=" but can't finish it yet.
Attachment #8538451 - Flags: review?(Pidgeot18)
(Assignee)

Comment 47

4 years ago
Created attachment 8538454 [details] [diff] [review]
An xpcshell test for url which has '&uidl=' (incomplete)

For the record, I am attaching the test for the url having '&uidl='.
(Reporter)

Comment 48

4 years ago
(In reply to Hiroyuki Ikezoe (:hiro) from comment #47)
> Created attachment 8538454 [details] [diff] [review]
> An xpcshell test for url which has '&uidl=' (incomplete)
> 
> For the record, I am attaching the test for the url having '&uidl='.

I wish Hiro's patch will be reviewed and incorporated soon.

In the meantime, I have a pile of local patches I need to sort out and
upload and so here is a quick cheat that I use to make C-C TB (full debug version) to run without the crash.

I am testing local C-C TB build for now by basically
(re)setting loadinfo in
comm-central/mozilla/netwerk/base/src/nsIOService.cpp
after a channel is created in
nsIOService::NewChannelFromURIWithProxyFlagsInternal(nsIURI* aURI,
if and only if the channel does not have non-null loadinfo and aloadinfo passed as argument is non null: the setting after the call to NewChannel2 seems to fix the temporary problem. (For example, it worked around the issue of
null loadinfo being passed to nsResProtocolHandler::NewChannel2.)

With this, I could test patches for other bugs.
For example, bug 1085382
Ideally, instead of crashing hard, it would be nice to print a stack backtrace
and keep on running bypassing the check on loadinfo and sandbox  
to figure out where the null loadinfo is being attached by the time NewChannelFromURIWithProxyFlagsInternal is called. But I have not come that far to change the code yet.
Such a change may help people to figure out the forgotten places for the proper fix of passing non-null loadinfo.

In any case, I hope a proper reviewer can check Hiro's patch and incorporate into the tree very soon.
 
TIA

Comment 49

4 years ago
<rant>I am still using attach_loadlin as workaround for my own builds. That could have been done for this bug also to gain more time for a real fix. </rant>
Attachment #8538452 - Flags: review?(Pidgeot18) → review+
(Assignee)

Updated

4 years ago
Keywords: checkin-needed
(In reply to Hartmut Figge from comment #49)
> <rant>I am still using attach_loadlin as workaround for my own builds. That
> could have been done for this bug also to gain more time for a real fix.
> </rant>

Well, I stay put with the 12 December (i.e. "last good") build. As soon as I see a FIXED resolution, I'm gonna rush and grab the next build, even an hourly, to try and get the L64 SeaMonkey part of this bug VERIFIED. (Someone else, or some other people, will have to test it on Windows and Mac; I have Thunderbird-Daily but the profile is not realistic; and IMHO a bug as important as this one should be tested exhaustively after landing the fix.)

Comment 51

4 years ago
(In reply to Tony Mechelynck [:tonymec] from comment #50)

Agreed. Mostly. The impact of a topcrash bug could be reduced by using a temporary workaround, though. When there are no builds, no new bugs can be found and the delay makes fixing more difficult.

Nevertheless, i do apologize for the rant. Here is not the right place for such.
Comment on attachment 8538451 [details] [diff] [review]
An xpcshell test that load imap url does not cause crash.

Review of attachment 8538451 [details] [diff] [review]:
-----------------------------------------------------------------

I don't think this test is necessary--we do enough IMAP tests that someone is going to end up covering this code: <http://www.tjhsst.edu/~jcranmer/c-ccov/mailnews/imap/src/nsImapService.cpp.html>.
Attachment #8538451 - Flags: review?(Pidgeot18) → review-
(Reporter)

Comment 53

4 years ago
Very strange, I still see null loadinfo passed to MOZ_ASSERT() even after applying Hiro's patch when
I manually invoke C-C TB (full debug build). 

I have no idea what is going on.

Can the execution path of TB be slightly different when it is controlled under mozmill instead being
run on a tty console?

TIA
(Reporter)

Comment 54

4 years ago
Created attachment 8539189 [details] [diff] [review]
temporary patch to keep on running to detect bad places.

(In reply to ISHIKAWA, Chiaki from comment #53)
> Very strange, I still see null loadinfo passed to MOZ_ASSERT() even after
> applying Hiro's patch when
> I manually invoke C-C TB (full debug build). 
> 
> I have no idea what is going on.
> 
> Can the execution path of TB be slightly different when it is controlled
> under mozmill instead being
> run on a tty console?
> 
> TIA

For completeness sake, I am uploading my first-aid patch to keep on running
after detecting the non-null loadinfo attached to a channel, so that
we can find out problematic places.


OK, I figured out how to obtain stack trace from
NS_ASSERTION();

export XPCOM_DEBUG_BREAK=stack

is the trick before running TB.

After applying Hiro's patch, the first instance of a channel created
and passed down with a null loadinfo was seen as in the following
stack trace: So it seems that Java Interpreter when it tries to read something(?) into its workspace is not setting loadinfo correctly at least in C-C TB environment?


[23714] ###!!! ASSERTION: null loadinfo was attached to a channel.: '0', file /new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/netwerk/base/src/nsIOService.cpp, line 701
#01: nsIOService::NewChannelFromURIWithProxyFlags2(nsIURI*, nsIURI*, unsigned int, nsIDOMNode*, nsIPrincipal*, nsIPrincipal*, unsigned int, unsigned int, nsIChannel**) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/netwerk/base/src/nsIOService.cpp:701)
#02: nsIOService::NewChannelFromURI(nsIURI*, nsIChannel**) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/netwerk/base/src/nsIOService.cpp:607)
#03: nsResProtocolHandler::NewChannel2(nsIURI*, nsILoadInfo*, nsIChannel**) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp:305)
#04: nsIOService::NewChannelFromURIWithProxyFlags2(nsIURI*, nsIURI*, unsigned int, nsIDOMNode*, nsIPrincipal*, nsIPrincipal*, unsigned int, unsigned int, nsIChannel**) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/netwerk/base/src/nsIOService.cpp:685)
#05: nsIOService::NewChannelFromURI(nsIURI*, nsIChannel**) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/netwerk/base/src/nsIOService.cpp:607)
#06: ComponentLoaderInfo::EnsureScriptChannel() (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:240)
#07: ComponentLoaderInfo::EnsureResolvedURI() (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:245 (discriminator 2))
#08: mozJSComponentLoader::ImportInto(nsACString_internal const&, JS::Handle<JSObject*>, JSContext*, JS::MutableHandle<JSObject*>) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:1111)
#09: mozJSComponentLoader::Import(nsACString_internal const&, JS::Handle<JS::Value>, JSContext*, unsigned char, JS::MutableHandle<JS::Value>) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:1043)
#10: nsXPCComponents_Utils::Import(nsACString_internal const&, JS::Handle<JS::Value>, JSContext*, unsigned char, JS::MutableHandle<JS::Value>) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/js/xpconnect/src/XPCComponents.cpp:2686)
#11: NS_InvokeByIndex (/home/ishikawa/objdir-tb3/dist/bin/libxul.so)
#12: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1736)
#13: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1174)
#14: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/js/src/jscntxtinlines.h:232)
#15: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/js/src/vm/Interpreter.cpp:482)
#16: Interpret(JSContext*, js::RunState&) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/js/src/vm/Interpreter.cpp:2539)
#17: js::RunScript(JSContext*, js::RunState&) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/js/src/vm/Interpreter.cpp:432)
#18: Could not determine endianness of /home/ishikawa/objdir-tb3/dist/bin/thunderbird
js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value const&, js::ExecuteType, js::AbstractFramePtr, JS::Value*) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/js/src/vm/Interpreter.h:159)
#19: js::Execute(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value*) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/js/src/vm/Interpreter.cpp:678)
#20: ExecuteScript(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSScript*>, JS::Value*) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/js/src/jsapi.cpp:4709)
#21: mozJSComponentLoader::ObjectForLocation(ComponentLoaderInfo&, nsIFile*, JS::MutableHandle<JSObject*>, JS::MutableHandle<JSScript*>, char**, bool, JS::MutableHandle<JS::Value>) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:935)
#22: mozJSComponentLoader::LoadModule(mozilla::FileLocation&) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:352)
#23: nsComponentManagerImpl::KnownModule::Load() (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/xpcom/components/nsComponentManager.cpp:851)
#24: nsFactoryEntry::GetFactory() (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/xpcom/components/nsComponentManager.cpp:1915)
#25: nsComponentManagerImpl::CreateInstanceByContractID(char const*, nsISupports*, nsID const&, void**) (/home/ishikawa/objdir-tb3/xpcom/components/../../dist/include/AlreadyAddRefed.h:85)
#26: CallCreateInstance(char const*, nsISupports*, nsID const&, void**) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/xpcom/glue/nsComponentManagerUtils.cpp:151)
#27: nsCreateInstanceByContractID::operator()(nsID const&, void**) const (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/xpcom/glue/nsComponentManagerUtils.cpp:198)
#28: nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const&, nsID const&) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/xpcom/glue/nsCOMPtr.cpp:125)
#29: nsAppStartupNotifier::Observe(nsISupports*, char const*, char16_t const*) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/embedding/components/appstartup/nsAppStartupNotifier.cpp:66)
#30: XREMain::XRE_mainRun() (/home/ishikawa/objdir-tb3/toolkit/xre/../../dist/include/nsCOMPtr.h:390)
#31: XREMain::XRE_main(int, char**, nsXREAppData const*) (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/toolkit/xre/nsAppRunner.cpp:4226)
#32: XRE_main (/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/toolkit/xre/nsAppRunner.cpp:4447)
#33: ??? (/home/ishikawa/objdir-tb3/dist/bin/thunderbird)
#34: ??? (/home/ishikawa/objdir-tb3/dist/bin/thunderbird)


PS: I feel this problematic loading of JS code by TB may have something to do with the failure to load profile package. Does TB have a slightly loading code sequence which is different from FF's (like forgetting to set some prerequisite data?)
Duplicate of this bug: 1113569
(Reporter)

Comment 56

4 years ago
(In reply to ISHIKAWA, Chiaki from comment #54)
> After applying Hiro's patch, the first instance of a channel created
> and passed down with a null loadinfo was seen as in the following
> stack trace: So it seems that Java Interpreter when it tries to read
> something(?) into its workspace is not setting loadinfo correctly at least
> in C-C TB environment?
> 
   ... backtrace, etc. omitted. ...

This trace was obtained on a PC without the patch to 
nsResProtocolHandler::NewChannel2 mentioned in 
> nsResProtocolHandler::NewChannel2(nsIURI* uri, ...) 
>fails to set nsILoadInfo by calling SetLoadInfo just
>before returning.
>..
>    (*result)->SetLoadInfo(aLoadInfo);

I have no access to PC for compiling new source patches over the weekend and so I will appreciate
other people trying to find the remaining culprit other then the
Java interpreter loading something into its workspace as noticed in comment 54.

Updated

4 years ago
Assignee: nobody → hiikezoe
Keywords: checkin-needed
Target Milestone: --- → Thunderbird 37.0
Duplicate of this bug: 1114015

Updated

4 years ago
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-seamonkey2.34: affected → fixed
status-thunderbird37: affected → fixed
Resolution: --- → FIXED
Mozilla/5.0 (X11; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0 SeaMonkey/2.34a1 ID:20141220003001 c-c:7a80103c70c5 m-c:490f124d7dea

This build of SeaMonkey for Linux64 is not affected by the bug (in a previous incarnation, it was "always").

Please check Windows, Mac and Thunderbird.
Keywords: verifyme
(Reporter)

Comment 60

4 years ago
Thanks for the latest patch.

It works and let me find out a few more issues in the current code
after running |make mozmill| successfully.  I think I already noticed
a newly introduced bug in the last few weeks when the test
cannot be run adequately enough due to the bustage.
( Bug 1114388 - Failure in nsAbQueryStringToExpression.cpp : ParseCondition (C-C TB) 

Also regarding the strange observation about
nsResProtcolHandler::NewChannel2 not not setting valid (non-null)
loadinfo despite the requirement that NewChannel2() of all protocol
handlers should set it, I filed Bug 1114386 -
nsResProtcolHandler::NewChannel2 fails to set loadinfo (edit) with
detailed stack trace, and I hope someone can figure out a correct way
to fix it.

Thank you again for the fix. I can now work on existing bugs.
See Also: → bug 1114386
(In reply to ISHIKAWA, Chiaki from comment #60)
> Thanks for the latest patch.
> 
> It works and [...]

Ishikawa-san, you're on Thunderbird aren't you? Which OS?
Flags: needinfo?(ishikawa)
(Reporter)

Comment 62

4 years ago
(In reply to Tony Mechelynck [:tonymec] from comment #61)
> (In reply to ISHIKAWA, Chiaki from comment #60)
> > Thanks for the latest patch.
> > 
> > It works and [...]
> 
> Ishikawa-san, you're on Thunderbird aren't you? Which OS?

Yes, I am testing comm-central thunderbird.
OS is Debian GNU/Linux, both 32-bit and 64-bit.

TIA
Flags: needinfo?(ishikawa)
At this URL:
https://crash-stats.mozilla.com/report/list?signature=nsIOService%3A%3ANewChannelFromURIWithProxyFlags2%28nsIURI*%2C+nsIURI*%2C+unsigned+int%2C+nsIDOMNode*%2C+nsIPrincipal*%2C+nsIPrincipal*%2C+unsigned+int%2C+unsigned+int%2C+nsIChannel**%29&range_value=7&range_unit=days#tab-reports
after clicking twice on "Build" to get the latest build ID on top, I see crashes from Thunderbird and SeaMonkey, and for Windows, Linux and Mac, but nothing later than 20141216030208.

Testing on Windows and Mac would IMHO still be desirable, but if all QA people are on Linux ;-) I propose to declare this fix VERIFIED if no new crashes appear in a "reasonable" time (let's say a fortnight or so).

Karsten, Wayne, what do you think?
Flags: needinfo?(vseerror)
Flags: needinfo?(mnyromyr)

Comment 64

4 years ago
I looked at this an hour ago and I am satisfied it is killed for Thunderbird.  Unfortunately, it is a startuup crash, and so it may be difficult for some users to be autoupdated. I emailed those few who provided email addresses with their crashes.

It would be nice if, like firefox, we auto emailed users who provide an address so we can give them instructions when relevant.
Flags: needinfo?(vseerror)
I didn't experience this bug at startup, only when opening either the preview pane or a separate message window, but the fact that my preview pane starts up closed may be due to an extension.

Failing autoupdate, it is of course always possible to update manually by downloading the latest nightly from ftp.mozilla.org. In that case, it is prudent to remove the existing installation directory (but not the profiles) with all its contents, to avoid problems due to obsolete versions of files deleted in the distribution. The installdir can then be recreated by installing the newly downloaded nightly.
Socorro is still seing crashes with this signature, but only for builds earlier than the fix. Only Thunderbird and not SeaMonkey, but for this kind of bug, SeaMonkey users have it easier, since unlike Thunderbird, SeaMonkey can be started without the mailer, in which case the crash will not happen and autoupdate (if not explicitly personalized away) will kick in.
Socorro report for this week (URL see comment #63) sees build ID datestamps between 2014-12-13 and 2014-12-16, nothing else; of these, one SeaMonkey crash and the rest on Thunderbird. Checks on recent builds of Linux SeaMonkey (i686 and x86_64 by ISHIKAWA Chiaki and x86_64 by me) and of Thunderbird (by Wayne Mery) show no crashes.

Like Wayne in comment #64, I am now statisfied that this crash bug is fixed on both Thunderbird and SeaMonkey. => VERIFIED.
Status: RESOLVED → VERIFIED
Flags: needinfo?(mnyromyr)
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.