Closed Bug 1038887 Opened 7 years ago Closed 7 years ago

crash with non-existing xslt file in ToNewCString(nsACString_internal const&)


(Core :: XPCOM, defect)

Not set



Tracking Status
firefox31 --- unaffected
firefox32 --- verified
firefox33 --- verified
firefox34 --- verified


(Reporter: martijn.martijn, Assigned: mccr8)



(Keywords: crash, regression, testcase)

Crash Data


(2 files)

Attached file testcase
See testcase, which crashes current trunk build. This was probably a regression from bug 972605.

This bug was filed from the Socorro interface and is 
report bp-1f9e4f9b-8397-4d77-b379-249622140715.
0 	XUL 	ToNewCString(nsACString_internal const&) 	xpcom/string/nsTSubstring.h
1 	XUL 	nsErrorService::GetErrorStringBundle(short, char**) 	xpcom/base/nsErrorService.cpp
2 	XUL 	nsStringBundleService::FormatStatusMessage(tag_nsresult, char16_t const*, char16_t**) 	intl/strres/src/nsStringBundle.cpp
3 	XUL 	txMozillaXSLTProcessor::reportError(tag_nsresult, char16_t const*, char16_t const*) 	dom/xslt/xslt/txMozillaXSLTProcessor.cpp
4 	XUL 	txStylesheetCompiler::cancel(tag_nsresult, char16_t const*, char16_t const*) 	dom/xslt/xslt/txStylesheetCompiler.cpp
5 	XUL 	txStylesheetSink::OnStopRequest(nsIRequest*, nsISupports*, tag_nsresult) 	dom/xslt/xslt/txMozillaStylesheetCompiler.cpp
6 	XUL 	nsCORSListenerProxy::OnStopRequest(nsIRequest*, nsISupports*, tag_nsresult) 	content/base/src/nsCrossSiteListenerProxy.cpp
7 	XUL 	mozilla::net::nsHttpChannel::OnStopRequest(nsIRequest*, nsISupports*, tag_nsresult) 	netwerk/protocol/http/nsHttpChannel.cpp
8 	XUL 	nsInputStreamPump::OnStateStop() 	netwerk/base/src/nsInputStreamPump.cpp
Ok, it doesn't crash online, because Nightly is blocking insecure content. Once you unblock it, then it crashes.
Assignee: nobody → continuation
Component: XSLT → XPCOM
Oops, looks like I accidentally dropped a null check in part 3.
OS: Mac OS X → All
This is a crash regression with a low risk fix.  Probably not a common crash.
Keywords: regression
try run that hasn't finished yet:

I just added the test as a crash test to a random XML-ish related directory, which is not the greatest.

Ideally there would be some kind of unit test for error service, but I started to try that and was getting a linking error about missing a vtable or something.
Attachment #8457618 - Flags: review?(nfroyd)
This signature is ranked 163 on Nightly.  The 6 reports I looked at all definitely looked like this issue.  I don't see it in the top 300 on Aurora.  Maybe the Nightly crashes are all people running this test case. :)
I guess this isn't really worth tracking.
Comment on attachment 8457618 [details] [diff] [review]
Add back null check to nsErrorService::GetErrorStringBundle.

Review of attachment 8457618 [details] [diff] [review]:

Attachment #8457618 - Flags: review?(nfroyd) → review+
Keywords: checkin-needed
Keywords: checkin-needed
Thanks for the test case!
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Comment on attachment 8457618 [details] [diff] [review]
Add back null check to nsErrorService::GetErrorStringBundle.

Approval Request Comment
[Feature/regressing bug #]: bug 972605
[User impact if declined]: crashes in some rare cases
[Describe test coverage new/current, TBPL]: test added on TBPL
[Risks and why]: very low, this just restores old behavior in one case
[String/UUID change made/needed]: none
Attachment #8457618 - Flags: approval-mozilla-beta?
Attachment #8457618 - Flags: approval-mozilla-aurora?
Flags: in-testsuite+
Attachment #8457618 - Flags: approval-mozilla-beta?
Attachment #8457618 - Flags: approval-mozilla-beta+
Attachment #8457618 - Flags: approval-mozilla-aurora?
Attachment #8457618 - Flags: approval-mozilla-aurora+
Verified fixed FF 32b4, 33.0a2 (2014-08-07), 34.0a1 (2014-08-07)
You need to log in before you can comment on or make changes to this bug.