Closed Bug 1111304 Opened 10 years ago Closed 10 years ago

assertion failure loadinfo

Categories

(MailNews Core :: Backend, defect)

Product:
MailNews Core
Component:
Backend
Platform:
x86_64
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(thunderbird37? fixed, seamonkey2.34? fixed)

Status:
VERIFIED FIXED
Milestone:
Thunderbird 37.0
Tracking Flags:
Tracking Status
thunderbird37 ? fixed
seamonkey2.34 ? fixed

People

(Reporter: ishikawa, Assigned: hiro)

References

Details

(4 keywords, Whiteboard: [startup crash])

Crash Data

Attachments

(5 files, 7 obsolete files)

A bug in nsResProtocolHandler.cpp ?
3.34 KB, patch
Details | Diff | Splinter Review
An xpcshell test that load imap url does not cause crash.
1.77 KB, patch
jcranmer
: review-
Details | Diff | Splinter Review
v5
12.90 KB, patch
jcranmer
: review+
Details | Diff | Splinter Review
An xpcshell test for url which has '&uidl=' (incomplete)
3.55 KB, patch
Details | Diff | Splinter Review
temporary patch to keep on running to detect bad places.
1.77 KB, patch
Details | Diff | Splinter Review
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$
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]
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.
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.
(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.
> 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
(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 ) { ... } ???
Blocks: 1087442
No longer depends on: 1087442
Keywords: regression
status-seamonkey2.34: --- → affected
status-thunderbird37: --- → affected
tracking-seamonkey2.34: --- → ?
tracking-thunderbird37: --- → ?
Version: unspecified → Trunk
(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.
So just applying patches in bug 1099587 is not enough? Is the loadinfo stuff new?
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
Attached patch patch_loadinfo (obsolete) — — Splinter Review
(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. ;)
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)
Attached patch attach_loadinfo (obsolete) — — Splinter Review
(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.
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-
Attached patch bug1111304.patch (obsolete) — — Splinter Review
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-
(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!
Attached patch v2 (obsolete) — — Splinter Review
https://treeherder.mozilla.org/ui/#/jobs?repo=try-comm-central&revision=6775687fa7dc
Attachment #8537542 - Attachment is obsolete: true
Attachment #8537565 - Flags: review?(mozilla)
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)
Attached patch v3 (obsolete) — — Splinter Review
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)
(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
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
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.
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-
Attached patch v4 (obsolete) — — Splinter Review
Fixed all pointed out in comment #35.
Attachment #8537595 - Attachment is obsolete: true
Attachment #8538097 - Flags: review?(Pidgeot18)
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.
(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
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.
I am trying to write another test for the url which has "uidl=" but can't finish it yet.
Attachment #8538451 - Flags: review?(Pidgeot18)
Attached patch v5 — — Splinter Review
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=d984bb9ab98d
Attachment #8538097 - Attachment is obsolete: true
Attachment #8538097 - Flags: review?(Pidgeot18)
Attachment #8538452 - Flags: review?(Pidgeot18)
For the record, I am attaching the test for the url having '&uidl='.
(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
<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+
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.)
(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-
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
(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?)
(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.
Assignee: nobody → hiikezoe
Keywords: checkin-needed
Target Milestone: --- → Thunderbird 37.0
Status: NEW → RESOLVED
Closed: 10 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
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: → 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)
(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)
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.

Attachment

General

Creator:
Created:
Updated:
Size: