Open Bug 1114386 Opened 10 years ago Updated 2 years ago

nsResProtcolHandler::NewChannel2 fails to set loadinfo

Tracking

()

Status:

NEW

People

(Reporter: ishikawa, Unassigned)

References

Details

(Whiteboard: [necko-backlog])

Attachments

(2 files)

A non-git patch to produce the stack dump explained in this report. 10 years ago ISHIKAWA, Chiaki 1.93 KB, patch		Details \| Diff \| Splinter Review
stack trace that leads to the use of @mozilla.org/nullprincipal;1 9 years ago ISHIKAWA, Chiaki 27.29 KB, text/x-log		Details

ISHIKAWA, Chiaki

Reporter

Description

•

10 years ago

Attached patch A non-git patch to produce the stack dump explained in this report. — Details — Splinter Review

nsResProtcolHandler::NewChannel2 fails to set loadinfo

(I am setting the component to JS engine since the JS engine ought to
provide the context/loadinfo as the original caller to the problematic
behavior.)

Despite the stated requirement that
NewChannel2() of all protocol handlers should set loadinfo,
(see bug Bug 1038756
or bug 1111304 that made me found this issue.)
nsResProtcolHandler::NewChannel2 is not setting valid (non-null)
loadinfo as far as I can tell (by instrumenting the code.)
when it is invoked during the execution of comm-central Thunderbird.

Despite the failure to set valid loadinfo by
nsResProtocolHanlder::NewChannel2, comm-central thunderbird seems to
run successfully for all practical purposes, AT LEAST NOW.

However, I think there is a dormant problem which may blow up in the
future someday.  (I don't understand the current security framework
very well. Is there a complete document that explains the grand
scheme, the current implementation status, and future path.?  Can this
failure of nsResProtcolHandler::NewChannel2 be ignored? I doubt it,
but not sure.)

So, here is the analysis based on the current code, and a suggested
fix (which lacks the essential element: which value to use for
aLoadingNode or aLoadingPrincipal. Any suggestions?)

Details:

The call to nsResProtcolHandler::NewChannel2, happens fairly early
after a startup of TB and when a .js or .jsm file is read by TB's JS
interpreter.

Below is the stack backtrace (at the end) and the brief analysis of
the first such call occurrence when |make mozmill| of debug build of
TB is executed. I dumped stack when nsResProtocolHandler::NewChannel2
failed to set non-null loadinfo when it returned (by NS_ASSERTION());
(See the attached patch to do this.)

The excerpted call sequence of several functions is below (the final
call first), and please note that a function,
nsIOService::NewChannelFromURI2, seems to be inlined and I don't seem
to see it in the stack trace although the source code suggests it
should be in the stack trace.

Brief stack trace analysis:

nsResProtocolHandler::NewChannel2

	<--- here the problem occurs. NewChannel2 is passed aLoadInfo
	which is nullptr, and the call to another function to set up
	channel is not setting up loadinfo properly.
 	When NewChannel2 is passed a null aLoadInfo, it calls
	       rv = mIOService->NewChannelFromURI(newURI, result);

        but this function call does not set loadinfo to the returned
        channel (**result).

nsIOService::NewChannelFromURIWithProxyFlagsInternal

nsIOService::NewChannelFromURIWithProxyFlags2
	(Note that  nsIOService::NewChannelFromURIWithProxyFlags2
	today tries to set a seemingly reasonable loadinfo to a
	channel internally when it calls
	NewChannelFromURIWithProxyFlagsInternal
	if loadinfo is missing (in order to not to break legacy addons
	according to the comment)
	AND if aLoadingNode or aLoadingPrincipal is available.
	    if (aLoadingNode || aLoadingPrincipal) ...

	But in this particular call sequence aLoadingNode and
	aLoadingPrincipal are both nullptr as explained below, and we fail.

nsIOService::NewChannelFromURI2	 (not in the stack trace in the
				 attached backtrace. maybe inlined?)

nsIOService::NewChannelFromURI
	this function calls NewChannelFromURI2 with null
	aLoadingNode, aLoadingPrincipal, and aTriggeringPrincipal.
	So eventual call to NewChannelfromURIWithProxyFlags2 cannot
	produce a satisfactory loadinfo because the contextual info
	is all null.

	     The call
	     return NewChannelFromURI2(aURI,
			    nullptr, // aLoadingNode
			    nullptr, // aLoadingPrincipal
			    nullptr, // aTriggeringPrincipal
			    nsILoadInfo::SEC_NORMAL,
			    nsIContentPolicy::TYPE_OTHER,
			    result);

ComponentLoaderInfo::EnsureScriptChannel
		Considering that the lower channel functions lack
		enough context, maybe we should change the following current
	       code

		nsresult EnsureScriptChannel() {
			BEGIN_ENSURE(ScriptChannel, IOService, URI);
			return mIOService->NewChannelFromURI(mURI, getter_AddRefs(mScriptChannel));
		 }

		by calling NewChannelFromURI2 directly with
		suitable LoadingNode, LoadingPrincipal info. I am not
		sure what the right value would be, though. Any suggestions?

		into 

		  return mIOService-> NewChannelFromURI2(mURI,
			    some-suitable-aLoadingNode // HERE
			    some-suitable-aLoadingPrincipal // HERE
			    some-suitable-aTriggeringPrincipal // HERE
			    nsILoadInfo::SEC_NORMAL,  // dont know if this is OK
			    nsIContentPolicy::TYPE_OTHER,  // 
			    getter_AddRefs(mScriptChannel))

ComponentLoaderInfo::EnsureResolvedURI
mozJSComponentLoader::ImportInto
... the rest is omitted ...


Full Stacktrace:

(debug) spec.get() was <<file:///REF-OBJ-DIR/objdir-tb3/dist/bin/modules/XPCOMUtils.jsm>> when calling mIOService->NewChannelFromURI: in nsResProtocolHandler::NewChannel2
[2886] ###!!! ASSERTION: (debug) NG nsResProtocolHandler::NewChannel2: checks null LoadInfo attached to a chanell and resets to value passed aLoadInfo, but aLoadInfo was null, too!.: '0', file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 328
#01: nsIOService::NewChannelFromURIWithProxyFlagsInternal(nsIURI*, nsIURI*, unsigned int, nsILoadInfo*, nsIChannel**) (/REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp:715)
#02: nsIOService::NewChannelFromURIWithProxyFlags2(nsIURI*, nsIURI*, unsigned int, nsIDOMNode*, nsIPrincipal*, nsIPrincipal*, unsigned int, unsigned int, nsIChannel**) (/REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp:838)
#03: nsIOService::NewChannelFromURI(nsIURI*, nsIChannel**) (/REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp:620)
#04: ComponentLoaderInfo::EnsureScriptChannel() (/REF-OBJ-DIR/objdir-tb3/js/xpconnect/loader/../../../dist/include/nsCOMPtr.h:686)
#05: ComponentLoaderInfo::EnsureResolvedURI() (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:245 (discriminator 2))
#06: mozJSComponentLoader::ImportInto(nsACString_internal const&, JS::Handle<JSObject*>, JSContext*, JS::MutableHandle<JSObject*>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:1111)
#07: mozJSComponentLoader::Import(nsACString_internal const&, JS::Handle<JS::Value>, JSContext*, unsigned char, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:1043)
#08: nsXPCComponents_Utils::Import(nsACString_internal const&, JS::Handle<JS::Value>, JSContext*, unsigned char, JS::MutableHandle<JS::Value>) (/REF-OBJ-DIR/objdir-tb3/js/xpconnect/src/../../../dist/include/nsCOMPtr.h:390)
#09: NS_InvokeByIndex (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp:166)
#10: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1737)
#11: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1174)
#12: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jscntxtinlines.h:232)
#13: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:482)
#14: Interpret(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:2539)
#15: js::RunScript(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:432)
#16: js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value const&, js::ExecuteType, js::AbstractFramePtr, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:641)
#17: js::Execute(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:678)
#18: ExecuteScript(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSScript*>, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jsapi.cpp:4309)
#19: mozJSComponentLoader::ObjectForLocation(ComponentLoaderInfo&, nsIFile*, JS::MutableHandle<JSObject*>, JS::MutableHandle<JSScript*>, char**, bool, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:935)
#20: mozJSComponentLoader::LoadModule(mozilla::FileLocation&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:352)
#21: nsComponentManagerImpl::KnownModule::Load() (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/components/nsComponentManager.cpp:851)
#22: nsFactoryEntry::GetFactory() (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/components/nsComponentManager.cpp:1915)
#23: nsComponentManagerImpl::CreateInstanceByContractID(char const*, nsISupports*, nsID const&, void**) (/REF-OBJ-DIR/objdir-tb3/xpcom/components/../../dist/include/AlreadyAddRefed.h:85)
#24: nsCreateInstanceByContractID::operator()(nsID const&, void**) const (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/nsComponentManagerUtils.cpp:198)
#25: nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const&, nsID const&) (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/nsCOMPtr.cpp:125)
#26: nsAppStartupNotifier::Observe(nsISupports*, char const*, char16_t const*) (/REF-COMM-CENTRAL/comm-central/mozilla/embedding/components/appstartup/nsAppStartupNotifier.cpp:66)
#27: XREMain::XRE_mainRun() (/REF-OBJ-DIR/objdir-tb3/toolkit/xre/../../dist/include/nsCOMPtr.h:390)
#28: XREMain::XRE_main(int, char**, nsXREAppData const*) (/REF-COMM-CENTRAL/comm-central/mozilla/toolkit/xre/nsAppRunner.cpp:4229)
#29: XRE_main (/REF-COMM-CENTRAL/comm-central/mozilla/toolkit/xre/nsAppRunner.cpp:4449)
#30: do_main(int, char**, nsIFile*) (/REF-COMM-CENTRAL/comm-central/mail/app/nsMailApp.cpp:188)
#31: main (/REF-COMM-CENTRAL/comm-central/mail/app/nsMailApp.cpp:400)
#32: __libc_start_main (/build/glibc-NmptCx/glibc-2.19/csu/libc-start.c:321)
#33: _start (/REF-OBJ-DIR/objdir-tb3/dist/bin/thunderbird)
#34: ??? (???:???)
(debug) spec.get() was <<file:///REF-OBJ-DIR/objdir-tb3/dist/bin/modules/Services.jsm>> when calling mIOService->NewChannelFromURI: in nsResProtocolHandler::NewChannel2
[2886] ###!!! ASSERTION: (debug) NG nsResProtocolHandler::NewChannel2: checks null LoadInfo attached to a chanell and resets to value passed aLoadInfo, but aLoadInfo was null, too!.: '0', file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 328
#01: nsIOService::NewChannelFromURIWithProxyFlagsInternal(nsIURI*, nsIURI*, unsigned int, nsILoadInfo*, nsIChannel**) (/REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp:715)
#02: nsIOService::NewChannelFromURIWithProxyFlags2(nsIURI*, nsIURI*, unsigned int, nsIDOMNode*, nsIPrincipal*, nsIPrincipal*, unsigned int, unsigned int, nsIChannel**) (/REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp:838)
#03: nsIOService::NewChannelFromURI(nsIURI*, nsIChannel**) (/REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp:620)
#04: ComponentLoaderInfo::EnsureScriptChannel() (/REF-OBJ-DIR/objdir-tb3/js/xpconnect/loader/../../../dist/include/nsCOMPtr.h:686)
#05: ComponentLoaderInfo::EnsureResolvedURI() (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:245 (discriminator 2))
#06: mozJSComponentLoader::ImportInto(nsACString_internal const&, JS::Handle<JSObject*>, JSContext*, JS::MutableHandle<JSObject*>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:1111)
#07: mozJSComponentLoader::Import(nsACString_internal const&, JS::Handle<JS::Value>, JSContext*, unsigned char, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:1043)
#08: nsXPCComponents_Utils::Import(nsACString_internal const&, JS::Handle<JS::Value>, JSContext*, unsigned char, JS::MutableHandle<JS::Value>) (/REF-OBJ-DIR/objdir-tb3/js/xpconnect/src/../../../dist/include/nsCOMPtr.h:390)
#09: NS_InvokeByIndex (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp:166)
#10: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1737)
#11: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1174)
#12: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jscntxtinlines.h:232)
#13: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:482)
#14: Interpret(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:2539)
#15: js::RunScript(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:432)
#16: js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value const&, js::ExecuteType, js::AbstractFramePtr, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:641)
#17: js::Execute(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:678)
#18: ExecuteScript(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSScript*>, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jsapi.cpp:4309)
#19: mozJSComponentLoader::ObjectForLocation(ComponentLoaderInfo&, nsIFile*, JS::MutableHandle<JSObject*>, JS::MutableHandle<JSScript*>, char**, bool, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:935)
#20: mozJSComponentLoader::LoadModule(mozilla::FileLocation&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:352)
#21: nsComponentManagerImpl::KnownModule::Load() (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/components/nsComponentManager.cpp:851)
#22: nsFactoryEntry::GetFactory() (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/components/nsComponentManager.cpp:1915)
#23: nsComponentManagerImpl::CreateInstanceByContractID(char const*, nsISupports*, nsID const&, void**) (/REF-OBJ-DIR/objdir-tb3/xpcom/components/../../dist/include/AlreadyAddRefed.h:85)
#24: nsCreateInstanceByContractID::operator()(nsID const&, void**) const (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/nsComponentManagerUtils.cpp:198)
#25: nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const&, nsID const&) (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/nsCOMPtr.cpp:125)
#26: nsAppStartupNotifier::Observe(nsISupports*, char const*, char16_t const*) (/REF-COMM-CENTRAL/comm-central/mozilla/embedding/components/appstartup/nsAppStartupNotifier.cpp:66)
#27: XREMain::XRE_mainRun() (/REF-OBJ-DIR/objdir-tb3/toolkit/xre/../../dist/include/nsCOMPtr.h:390)
#28: XREMain::XRE_main(int, char**, nsXREAppData const*) (/REF-COMM-CENTRAL/comm-central/mozilla/toolkit/xre/nsAppRunner.cpp:4229)
#29: XRE_main (/REF-COMM-CENTRAL/comm-central/mozilla/toolkit/xre/nsAppRunner.cpp:4449)
#30: do_main(int, char**, nsIFile*) (/REF-COMM-CENTRAL/comm-central/mail/app/nsMailApp.cpp:188)
#31: main (/REF-COMM-CENTRAL/comm-central/mail/app/nsMailApp.cpp:400)
#32: __libc_start_main (/build/glibc-NmptCx/glibc-2.19/csu/libc-start.c:321)
#33: _start (/REF-OBJ-DIR/objdir-tb3/dist/bin/thunderbird)
#34: ??? (???:???)


(debug) spec.get() was <<file:///REF-OBJ-DIR/objdir-tb3/dist/bin/modules/XPCOMUtils.jsm>> when calling mIOService->NewChannelFromURI: in nsResProtocolHandler::NewChannel2
(debug) fixing broken NewChannelfromURI implementation by setting aLoadInfo
[6557] ###!!! ASSERTION: (debug) NG nsResProtocolHandler::NewChannel2: checks null LoadInfo attached to a chanell and resets to value passed aLoadInfo, but aLoadInfo was null, too!.: '0', file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 331
#01: nsIOService::NewChannelFromURIWithProxyFlagsInternal(nsIURI*, nsIURI*, unsigned int, nsILoadInfo*, nsIChannel**) (/REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp:715)
#02: nsIOService::NewChannelFromURIWithProxyFlags2(nsIURI*, nsIURI*, unsigned int, nsIDOMNode*, nsIPrincipal*, nsIPrincipal*, unsigned int, unsigned int, nsIChannel**) (/REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp:838)
#03: nsIOService::NewChannelFromURI(nsIURI*, nsIChannel**) (/REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsIOService.cpp:620)
#04: ComponentLoaderInfo::EnsureScriptChannel() (/REF-OBJ-DIR/objdir-tb3/js/xpconnect/loader/../../../dist/include/nsCOMPtr.h:686)
#05: ComponentLoaderInfo::EnsureResolvedURI() (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:245 (discriminator 2))
#06: mozJSComponentLoader::ImportInto(nsACString_internal const&, JS::Handle<JSObject*>, JSContext*, JS::MutableHandle<JSObject*>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:1111)
#07: mozJSComponentLoader::Import(nsACString_internal const&, JS::Handle<JS::Value>, JSContext*, unsigned char, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:1043)
#08: nsXPCComponents_Utils::Import(nsACString_internal const&, JS::Handle<JS::Value>, JSContext*, unsigned char, JS::MutableHandle<JS::Value>) (/REF-OBJ-DIR/objdir-tb3/js/xpconnect/src/../../../dist/include/nsCOMPtr.h:390)
#09: NS_InvokeByIndex (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp:166)
#10: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1737)
#11: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1174)
#12: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jscntxtinlines.h:232)
#13: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:482)
#14: Interpret(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:2539)
#15: js::RunScript(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:432)
#16: js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value const&, js::ExecuteType, js::AbstractFramePtr, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:641)
#17: js::Execute(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:678)
#18: ExecuteScript(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSScript*>, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jsapi.cpp:4309)
#19: mozJSComponentLoader::ObjectForLocation(ComponentLoaderInfo&, nsIFile*, JS::MutableHandle<JSObject*>, JS::MutableHandle<JSScript*>, char**, bool, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:935)
#20: mozJSComponentLoader::LoadModule(mozilla::FileLocation&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp:352)
#21: nsComponentManagerImpl::KnownModule::Load() (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/components/nsComponentManager.cpp:851)
#22: nsFactoryEntry::GetFactory() (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/components/nsComponentManager.cpp:1915)
#23: nsComponentManagerImpl::CreateInstanceByContractID(char const*, nsISupports*, nsID const&, void**) (/REF-OBJ-DIR/objdir-tb3/xpcom/components/../../dist/include/AlreadyAddRefed.h:85)
#24: nsCreateInstanceByContractID::operator()(nsID const&, void**) const (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/nsComponentManagerUtils.cpp:198)
#25: nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const&, nsID const&) (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/nsCOMPtr.cpp:125)
#26: nsAppStartupNotifier::Observe(nsISupports*, char const*, char16_t const*) (/REF-COMM-CENTRAL/comm-central/mozilla/embedding/components/appstartup/nsAppStartupNotifier.cpp:66)
#27: XREMain::XRE_mainRun() (/REF-OBJ-DIR/objdir-tb3/toolkit/xre/../../dist/include/nsCOMPtr.h:390)
#28: XREMain::XRE_main(int, char**, nsXREAppData const*) (/REF-COMM-CENTRAL/comm-central/mozilla/toolkit/xre/nsAppRunner.cpp:4229)
#29: XRE_main (/REF-COMM-CENTRAL/comm-central/mozilla/toolkit/xre/nsAppRunner.cpp:4449)
#30: do_main(int, char**, nsIFile*) (/REF-COMM-CENTRAL/comm-central/mail/app/nsMailApp.cpp:188)
#31: main (/REF-COMM-CENTRAL/comm-central/mail/app/nsMailApp.cpp:400)
#32: __libc_start_main (/build/glibc-NmptCx/glibc-2.19/csu/libc-start.c:321)
#33: _start (/REF-OBJ-DIR/objdir-tb3/dist/bin/thunderbird)
#34: ??? (???:???)

TIA

ISHIKAWA, Chiaki

Reporter

Updated

•

10 years ago

Comment 1

•

9 years ago

I found that this is also an issue with firefox created from M-C portion of C-C tree.

The loading of local .js, .jsm seem to follow similar path thus
the same issue.

I think since FF and TB need to trust the locally installed (and used by run-time)
java script modules, we can simply use the system principal, but
again, since I don't know the grand security framework, I will wait for some comments from people in the know.

TIA

ISHIKAWA, Chiaki

Reporter

Comment 2

•

9 years ago

(In reply to ISHIKAWA, Chiaki from comment #1)
> I found that this is also an issue with firefox created from M-C portion of
> C-C tree.
> 

A console log immediately after firefox (M-C portion of C-C) is run:


$ ~/ff-objdir-tb3/dist/bin/firefox
(debug) spec.get() was <<file:///home/ishikawa/ff-objdir-tb3/dist/bin/modules/Preferences.jsm>> when calling mIOService->NewChannelFromURI: in nsResProtocolHandler::NewChannel2
[2733] ###!!! ASSERTION: (debug) NG LoadInfo attached to a chanell is null, but aLoadInfo was null, too!.: '0', file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 330
(debug) spec.get() was <<file:///home/ishikawa/ff-objdir-tb3/dist/bin/modules/XPCOMUtils.jsm>> when calling mIOService->NewChannelFromURI: in nsResProtocolHandler::NewChannel2
[2733] ###!!! ASSERTION: (debug) NG LoadInfo attached to a chanell is null, but aLoadInfo was null, too!.: '0', file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 330
(debug) spec.get() was <<file:///home/ishikawa/ff-objdir-tb3/dist/bin/modules/Services.jsm>> when calling mIOService->NewChannelFromURI: in nsResProtocolHandler::NewChannel2
[2733] ###!!! ASSERTION: (debug) NG LoadInfo attached to a chanell is null, but aLoadInfo was null, too!.: '0', file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 330
(debug) spec.get() was <<file:///home/ishikawa/ff-objdir-tb3/dist/bin/modules/XPCOMUtils.jsm>> when calling mIOService->NewChannelFromURI: in nsResProtocolHandler::NewChannel2
[2733] ###!!! ASSERTION: (debug) NG LoadInfo attached to a chanell is null, but aLoadInfo was null, too!.: '0', file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 330
(debug) spec.get() was <<file:///home/ishikawa/ff-objdir-tb3/dist/bin/modules/XPCOMUtils.jsm>> when calling mIOService->NewChannelFromURI: in nsResProtocolHandler::NewChannel2



But with firefox in M-C portion of C-C, I see an interesting line later in the console log
Please note "(debug) owner is set to @mozilla.org/nullprincipal;1 in LoadURI" line below.

       ... excerpt from the console log  ....
(debug) spec.get() was <<file:///home/ishikawa/ff-objdir-tb3/dist/bin/modules/Timer.jsm>> when calling mIOService->NewChannelFromURI: in nsResProtocolHandler::NewChannel2
[Child 2773] ###!!! ASSERTION: (debug) NG LoadInfo attached to a chanell is null, but aLoadInfo was null, too!.: '0', file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 330
(debug) owner is set to @mozilla.org/nullprincipal;1 in LoadURI <== *HERE*
(debug) before InternalLoad in LoadURI
(debug) spec.get() was <<file:///home/ishikawa/ff-objdir-tb3/dist/bin/browser/modules/E10SUtils.jsm>> when calling mIOService->NewChannelFromURI: in nsResProtocolHandler::NewChannel2
[Child 2773] ###!!! ASSERTION: (debug) NG LoadInfo attached to a chanell is null, but aLoadInfo was null, too!.: '0', file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 330
(debug) spec.get() was <<file:///home/ishikawa/ff-objdir-tb3/dist/bin/modules/Services.jsm>> when calling mIOService->NewChannelFromURI: in nsResProtocolHandler::NewChannel2
[Child 2773] ###!!! ASSERTION: (debug) NG LoadInfo attached to a chanell is null, but aLoadInfo was null, too!.: '0', file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 330
(debug) finally DoURILoad in InternalLoad
(debug) before calling NS_NEWChannelInternal with six (6)arguments in DoURILoad
(debug) NS_NEWChannelInternal succeeded in DoURILoad
(debug) before InternalLoad in LoadURI
(debug) spec.get() was <<file:///home/ishikawa/ff-objdir-tb3/dist/bin/modules/TelemetryStopwatch.jsm>> when calling mIOService->NewChannelFromURI: in nsResProtocolHandler::NewChannel2
[Parent 2733] ###!!! ASSERTION: (debug) NG LoadInfo attached to a chanell is null, but aLoadInfo was null, too!.: '0', file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/protocol/res/nsResProtocolHandler.cpp, line 330
(debug) finally DoURILoad in InternalLoad
	... ...

I have never seen  the
"@mozilla.org/nullprincipal;1" log line when I run C-C T-B (not a single line when I execute |make mozmill| test suite.

TIA

Tony Mechelynck [:tonymec]

Comment 3

•

9 years ago

"The mozilla-central portion of the comm-central tree" is a copy of the official mozilla-central repository as it was the last time you ran "python client.py checkout" in comm-central — that should be no older than immediately before your latest compile, and more recent if you refreshed it since then.

To know how fresh that copy is, run "hg log -R ./mozilla -r default -l 1" (without the quotes of course) on your comm-central clone, and compare that with https://hg.mozila.org/mozilla-central/ This shows you your latest mozilla-central changeset on the default branch.

Tony Mechelynck [:tonymec]

Comment 4

•

9 years ago

oops: https://hg.mozilla.org/mozilla-central/ with two l's in mozilla.org

ISHIKAWA, Chiaki

Reporter

Comment 5

•

9 years ago

(In reply to Tony Mechelynck [:tonymec] from comment #3)
> "The mozilla-central portion of the comm-central tree" is a copy of the
> official mozilla-central repository as it was the last time you ran "python
> client.py checkout" in comm-central — that should be no older than
> immediately before your latest compile, and more recent if you refreshed it
> since then.
> 
> To know how fresh that copy is, run "hg log -R ./mozilla -r default -l 1"
> (without the quotes of course) on your comm-central clone, and compare that
> with https://hg.mozila.org/mozilla-central/ This shows you your latest
> mozilla-central changeset on the default branch.

Mine is : (after going down to ./mozilla branch and setting LANG=C since, otherwise,
the row headers appear in Japanese) is:


env LANG=C hg log -R ./ -r default -l 1
changeset:   221414:67c42c076393
tag:         tip
user:        ffxbld
date:        Sat Dec 27 03:21:34 2014 -0800
summary:     No bug, Automated blocklist update from host b-linux64-ix-0002 - a=blocklist-update

[This after removing the local patches that have been applied by hg queue features.]

I compared with hg.mozilla.org and looks many patches have been applied in the last couple of days. I refresh comm-central (and the ./mozilla portion together) and
see if there is a change or so.

It would be interesting to learn which part of ./m-c firefox sets owner (probably meaning the loadingNode), as in

(debug) owner is set to @mozilla.org/nullprincipal;1 in LoadURI <== *HERE*


The parts that forget to set owner (within m-c Firefox and
c-c TB) can probably learn from it and set owner accordingly.

TIA

ISHIKAWA, Chiaki

Reporter

Comment 6

•

9 years ago

(In reply to ISHIKAWA, Chiaki from comment #5)
> (In reply to Tony Mechelynck [:tonymec] from comment #3)
>
  [... omission ...]

> It would be interesting to learn which part of ./m-c firefox sets owner
> (probably meaning the loadingNode), as in
> 
> (debug) owner is set to @mozilla.org/nullprincipal;1 in LoadURI <== *HERE*
> 

Finding out to see where this is called under which condition turn out to be very difficult.

REASON: for whatever the reason, this seems to be generated in a timing-dependent manner, and sometimes it is not generated (!).

This I found out after trying to run full DEBUG version of firefox under gdb, and
setting breakpoint where the above line is printed.
It is most likely that the above line is NOT printed when I set the breakpoint.
It may suggest that multithreading has some issue here.
On a hunch, I ran |mach run| and |mach run --debug| a few times, and I found out
that sometimes the above line is NOT printed even under a simple |mach run|. Agha.
So depending on a certain thread that runs first, 
the condition that would trigger the following line is not satisfied any more...
> (debug) owner is set to @mozilla.org/nullprincipal;1 in LoadURI <== *HERE*

That this line gets printed fairly early in the initialization of firefox, I think
it has something to do with the internal loading of essential javascript,
and it seems to be related to a serious race issue in the initialization code of FF.


Note from the log in the following:
 - XPCOM object initialization run time issue logged prior to the message.
 - WARNING: '!compMgr', file /REF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/nsComponentManagerUtils.cpp, line 63
   suggests that component manger is not set up properly yet, even.
 - then "WARNING: Error constructing actor PJavaScriptChild".
   So obviously a certain race issue exists in the initialization code.
 - WARNING: Could not get disk information from DiskSpaceWatcher: file /REF-COMM-CENTRAL/comm-central/mozilla/dom/storage/DOMStorageIPC.cpp, line 319
   suggests an important check for disk file space was
   not available. And this check probably happens during initialization. 
Then we get the message about "@mozilla.org/nullprincipal;1". 

So I would think that the use of 
"@mozilla.org/nullprincipal;1" happens during early phase of initialization of FF,
and it may be happen only when a race condition in the initialization code
of FF manifests itself. Anyway, the race conditions that seem to exist
make it hard to analyze this issue at hand.
From the excerpt of local DEBUG version FF log:
Under Debian GNU/Linux 64-bit. So "Child" probably means "cloned" (linux parlance)
thread, or something.

  [...]
[20405] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80040111: file /REF-COMM-CENTRAL/comm-central/mozilla/dom/base/nsFrameLoader.cpp, line 288
++DOMWINDOW == 9 (0x1c34be0) [pid = 20405] [serial = 9] [outer = 0x1bc1cb0]
(debug) before InternalLoad in LoadURI
[20405] WARNING: NS_ENSURE_TRUE(nsContentUtils::GetCurrentJSContext()) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/docshell/base/nsDocShell.cpp, line 9154
(debug) finally DoURILoad in InternalLoad
(debug) before calling NS_NEWChannelInternal with six (6)arguments in DoURILoad
(debug) NS_NEWChannelInternal succeeded in DoURILoad
(debug) owner is set to nullptr in LoadURI  <-*-*-*- nullptr is used previosly.
(debug) before InternalLoad in LoadURI
(debug) finally DoURILoad in InternalLoad
(debug) before calling NS_NEWChannelInternal with six (6)arguments in DoURILoad
(debug) NS_NEWChannelInternal succeeded in DoURILoad
(debug) owner is set to nullptr in LoadURI
(debug) before InternalLoad in LoadURI
(debug) finally DoURILoad in InternalLoad
(debug) before calling NS_NEWChannelInternal with six (6)arguments in DoURILoad
(debug) NS_NEWChannelInternal succeeded in DoURILoad
[New Thread 0x7fff7b7ae700 (LWP 20444)]
[20405] WARNING: Subdocument container has no frame: file /REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsDocumentViewer.cpp, line 2505
++DOMWINDOW == 10 (0x1dcc480) [pid = 20405] [serial = 10] [outer = 0x14e4ba0]
[20405] WARNING: Subdocument container has no frame: file /REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsDocumentViewer.cpp, line 2505
++DOMWINDOW == 11 (0x1dd80f0) [pid = 20405] [serial = 11] [outer = 0x14e8430]
++DOMWINDOW == 12 (0x1ca9230) [pid = 20405] [serial = 12] [outer = 0x1bc1cb0]
    * * * * note that XPCOM object initialization run time issue logged here. This suggests that some objects are created for the first time here. Thus this is 
in the initialization part of FF, I think. * * * *
[20445] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /REF-COMM-CENTRAL/comm-central/mozilla/xpcom/base/nsTraceRefcnt.cpp, line 143
[20445] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /REF-COMM-CENTRAL/comm-central/mozilla/xpcom/base/nsTraceRefcnt.cpp, line 143
[20445] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /REF-COMM-CENTRAL/comm-central/mozilla/xpcom/base/nsTraceRefcnt.cpp, line 143
[Parent 20405] WARNING: No docshells for remote frames!: file /REF-COMM-CENTRAL/comm-central/mozilla/dom/base/nsFrameLoader.cpp, line 514
* * * Child process/clone/thread sees !compMgr, which suggests that component
manager is not properly initialized yet. * * *
[Child 20445] WARNING: '!compMgr', file /REF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/nsComponentManagerUtils.cpp, line 63
[Child 20445] WARNING: NS_ENSURE_TRUE(svc) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/dom/ipc/nsIContentChild.cpp, line 32
* * * the following suggest a serious error ... * * *
[Child 20445] WARNING: Error constructing actor PJavaScriptChild: file /home/ishikawa/ff-objdir-tb3/ipc/ipdl/PContentChild.cpp, line 932
[New Thread 0x7fff7af5d700 (LWP 20447)]
[Child 20445] WARNING: '!compMgr', file /REF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/nsComponentManagerUtils.cpp, line 63
[New Thread 0x7fff7a70c700 (LWP 20458)]
[New Thread 0x7fffb13ae700 (LWP 20459)]
JavaScript strict warning: resource://gre/modules/Webapps.jsm, line 1198: ReferenceError: reference to undefined property msg.app
[Child 20445] WARNING: nsWindow::GetNativeData not implemented for this type: file /REF-COMM-CENTRAL/comm-central/mozilla/widget/PuppetWidget.cpp, line 824
++DOCSHELL 0x8a1cb0 == 1 [pid = 20445] [id = 1]
++DOMWINDOW == 1 (0x9391a0) [pid = 20445] [serial = 1] [outer = (nil)]
JavaScript strict warning: file:///home/ishikawa/ff-objdir-tb3/dist/bin/components/nsSearchService.js, line 3522: ReferenceError: reference to undefined property json._dataType
JavaScript strict warning: file:///home/ishikawa/ff-objdir-tb3/dist/bin/components/nsSearchService.js, line 1047: ReferenceError: reference to undefined property param.purpose
++DOMWINDOW == 2 (0xa00980) [pid = 20445] [serial = 2] [outer = 0x9391a0]
[New Thread 0x7fff7a14f700 (LWP 20463)]
[New Thread 0x7fff798fe700 (LWP 20464)]
* * * * The following suggests an important check for disk file space was
not available. And it probably happens during initialization. 
Then we get the message about " @mozilla.org/nullprincipal;1". * * *
[Parent 20405] WARNING: Could not get disk information from DiskSpaceWatcher: file /REF-COMM-CENTRAL/comm-central/mozilla/dom/storage/DOMStorageIPC.cpp, line 319
(debug) owner is set to @mozilla.org/nullprincipal;1 in LoadURI
(debug) before InternalLoad in LoadURI
(debug) finally DoURILoad in InternalLoad
(debug) before calling NS_NEWChannelInternal with six (6)arguments in DoURILoad
(debug) NS_NEWChannelInternal succeeded in DoURILoad
(debug) before InternalLoad in LoadURI
(debug) finally DoURILoad in InternalLoad
(debug) before calling NS_NEWChannelInternal with six (6)arguments in DoURILoad
(debug) NS_NEWChannelInternal succeeded in DoURILoad
[Child 20445] WARNING: NS_ENSURE_TRUE(node) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsDocumentViewer.cpp, line 3524
[Child 20445] WARNING: NS_ENSURE_TRUE(node) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsDocumentViewer.cpp, line 3524


PS: mozilla community should pay more serious attention to the issue of races
during initialization and SHUTDOWN phase of programs.
The latter, the shutdown phase race must have been the cause of many crashes of thunderbird and firefox. For example, just testing FF only a few times under gdb, I got
the following (!). Amazing...

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff57526700 (LWP 20625)]
mozilla::(anonymous namespace)::RunWatchdog (arg=<optimized out>)
    at /REF-COMM-CENTRAL/comm-central/mozilla/toolkit/components/terminator/nsTerminator.cpp:151
151	    MOZ_CRASH("Shutdown too long, probably frozen, causing a crash.");

Obviously, running firefox under gdb changed timing of thread execution enough so that
some hidden synchronization issues surfaced (leading to a deadlock or something)
and I saw the the above crash initiazed by a watchdog routine.
 
Anyway, I could obtain the stack trace. More in the next message.

TIA

ISHIKAWA, Chiaki

Reporter

Comment 7

•

9 years ago

Attached file stack trace that leads to the use of @mozilla.org/nullprincipal;1 — Details

Manually trying to catch the execution of the use of
@mozilla.org/nullprincipal;1 using gdb was difficult, and so I inserted
MOZ_CRASH(0, ...) at the line where this value was used and hoped I
would get a nice stack dump soon after repeating the execution of FF.
On the first try (!), I got the hit
and obtained a dump. (It seems that I can obtain dumps almost
always. Funny. Again, race issues manifest in mysterious manners.)

When FF was forced to crash  upon its attempt to use
@mozilla.org/nullprincipal;1, it was drawing an initial tab (in a cloned
child/thread) and the screen showed the

--- begin quote
Tab crashed
Well, this is embarrassing. We tried to display
this Web page, but it's not responding 
[try again]
--- end quote

And this is the initial (and only) tab and so
there is nothing to see except for this error message.

So it seems that a cloned (thread) was invoked to draw a tab, and the
nullprincipal was going to be used there in the current security framework
(and the current interim code implementation).

This observation matches the code in nsDocShell.cpp
http://mxr.mozilla.org/comm-central/source/mozilla/docshell/base/nsDocShell.cpp#1588

    if (aLoadFlags & LOAD_FLAGS_DISALLOW_INHERIT_OWNER) {
        inheritOwner = false;
        owner = do_CreateInstance("@mozilla.org/nullprincipal;1");

I assume FF is invoking the cloned thread/process in a separate
context (so that the main thread would not crash even if a web page
caused the drawing engine to crash, etc.), and when it invokes such a
clone, it hands off the clone by having it not inherit the owner ( a
flag with LOAD_FLAGS_DISALLOW_INHERIT_OWNER bit set was handed down
from the original invoker, I think.) so that the clone assumes an owner without
special privilege.

TB might want to follow suit by using mozilla.org/nullprincipal;1 in
LoadURI2() since this principal seems to be the least privileged owner
principal. [This is *if and only if* we should set loadinfo calls to relevant
functions defined in nsResProtocolHandler.cpp. But it seems that we
should set loadinfor properly for all these routines. ]
The value is security-related, however,  and so we may need more careful
investigation and pondering.


Anyway, attached is the execution log that includes stacktrace captured
by crashing FF forcibly when the code snippet

        owner = do_CreateInstance("@mozilla.org/nullprincipal;1");

is invoked.  Note that due to the debug statements, the line numbers
in the stack are slightly off from MXR listing.

Also, the various environment variables may have some bearings on what
happens here, I quote the dump of shell script preceding the
invocation of "gdb ...firefox-binary..." (mach run --debug) 
that leads to the forced crash to capture the stacktrace (sanitized by
mozilla/tools/rb/fix_linux_stack.py script to obtain symbolic trace.)

TIA

Boris Zbarsky [:bzbarsky]

Comment 8

•

7 years ago

Is this still an issue?  nsresProtocolHandler::NewChannel2 no longer exists, but SubstitutingProtocolHandler::NewChannel2( would get called and uses the loadinfo correctly at first glance.

Flags: needinfo?(ishikawa)

Jeff Walden [:Waldo]

Comment 9

•

7 years ago

Notwithstanding comment 0, I'm pretty sure this is not in the JS engine's domain.

Component: JavaScript Engine → Networking

ISHIKAWA, Chiaki

Reporter

Comment 10

•

7 years ago

(In reply to Boris Zbarsky [:bz] (still a bit busy) (if a patch has no decent message, automatic r-) from comment #8)
> Is this still an issue?  nsresProtocolHandler::NewChannel2 no longer exists,
> but SubstitutingProtocolHandler::NewChannel2( would get called and uses the
> loadinfo correctly at first glance.

Let me check. I am in the process of reassembling my PC due to memory issues and also can't do it quickly enough due to back pain :-(

Flags: needinfo?(ishikawa)

Daniel Stenberg [:bagder]

Updated

•

7 years ago

Whiteboard: [necko-backlog]

Firefox Bug Husbandry Bot

Comment 11

•

7 years ago

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Priority: -- → P1

Firefox Bug Husbandry Bot

Comment 12

•

7 years ago

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Priority: P1 → P3

BMO Automation

Updated

•

2 years ago

Severity: normal → S3

You need to log in before you can comment on or make changes to this bug.

Bugzilla

Quick Search

nsResProtcolHandler::NewChannel2 fails to set loadinfo

Categories

(Core :: Networking, defect, P3)

Tracking

()

People

(Reporter: ishikawa, Unassigned)

References

Details

(Whiteboard: [necko-backlog])

Crash Data

Security

(public)

User Story

Attachments

(2 files)

Description

Updated

Comment 1

Comment 2

Comment 3

Comment 4

Comment 5

Comment 6

Comment 7

Comment 8

Comment 9

Comment 10

Updated

Comment 11

Comment 12

Updated

Attachment

General

Description

File Name

Content Type