Closed
Bug 1286082
Opened 8 years ago
Closed 6 years ago
1,300 instances of "NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8007000E" emitted from dom/xul/nsXULPrototypeCache.cpp during linux64 debug testing
Categories
(Core :: XUL, defect, P3)
Core
XUL
Tracking
()
RESOLVED
FIXED
People
(Reporter: erahm, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
|
1.26 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
> 1313 WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8007000E: file dom/xul/nsXULPrototypeCache.cpp, line 323 This warning [1] shows up in the following test suites: > 233 - [TC] Linux64 mochitest-devtools-chrome-9 dt9 > 217 - [TC] Linux64 mochitest-devtools-chrome-10 dt10 > 205 - [TC] Linux64 mochitest-devtools-chrome-3 dt3 > 151 - [TC] Linux64 mochitest-devtools-chrome-5 dt5 > 96 - [TC] Linux64 mochitest-devtools-chrome-7 dt7 > 94 - [TC] Linux64 mochitest-devtools-chrome-8 dt8 > 90 - [TC] Linux64 mochitest-devtools-chrome-4 dt4 > 81 - [TC] Linux64 mochitest-devtools-chrome-2 dt2 > 47 - [TC] Linux64 mochitest-devtools-chrome-6 dt6 > 41 - [TC] Linux64 mochitest-devtools-chrome-1 dt1 > 24 - [TC] Linux64 mochitest-clipboard cl > 20 - [TC] Linux64 mochitest-clipboard-e10s cl > 6 - [TC] Linux64 mochitest-chrome-1 c1 > 6 - [TC] Linux64 mochitest-jetpack JP > 1 - [TC] Linux64 mochitest-browser-chrome-5 bc5 > 1 - [TC] Linux64 mochitest-browser-chrome-e10s-2 bc2 It shows up in 1218 tests. A few of the most prevalent: > 7 - devtools/client/debugger/test/mochitest/browser_dbg_host-layout.js > 7 - devtools/client/netmonitor/test/browser_net_prefs-reload.js > 6 - devtools/client/webconsole/test/browser_webconsole_bug_752559_ineffective_iframe_sandbox_warning.js > 5 - devtools/client/webconsole/test/browser_console_history_persist.js > 4 - devtools/client/webide/test/test_toolbox.html > 4 - devtools/client/webconsole/test/browser_webconsole_netlogging.js > 4 - devtools/client/webconsole/test/browser_webconsole_bug_595350_multiple_windows_and_tabs.js > 4 - devtools/client/framework/test/browser_toolbox_toggle.js > 4 - devtools/client/framework/test/browser_toolbox_options_disable_cache-02.js > 3 - devtools/client/webconsole/test/browser_webconsole_bug_622303_persistent_filters.js [1] https://hg.mozilla.org/mozilla-central/annotate/214884d507ee/dom/xul/nsXULPrototypeCache.cpp#l323
|
Reporter | |
Comment 1•8 years ago
|
||
Bisection points to bug 1233463 (or possibly bug 1252247) [1]. Lets move this over to devtools. [1] https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=0cc84e26a640b2f8217a1983989cfba69ea9b280&tochange=360e21e14e09be0c9aa607a0d7d256b0f5a2bc5b
Blocks: 1233463
Component: DOM → Developer Tools: Framework
Flags: needinfo?(poirot.alex)
Product: Core → Firefox
|
||
Comment 2•8 years ago
|
||
Thanks for the bisection. Yes, it looks like XUL doesn't like to be hosted on a about: page.
Flags: needinfo?(poirot.alex)
|
|
||
Comment 4•8 years ago
|
||
It looks like a typo within XUL codebase rather than something weird in devtools. I have no idea what it is about but there is a typo here that forces returning OUT_OF_MEMORY and introduce this warning during devtools tests. Any idea who should review that?
Priority: -- → P3
|
|
Reporter | |
Comment 5•8 years ago
|
||
Comment on attachment 8770138 [details] [diff] [review] Fix XULPrototypeCache typo Nice catch! That seems to have fixed the warning in the try run. bz, is this something you can review?
Attachment #8770138 -
Flags: review?(bzbarsky)
|
||
Comment 6•8 years ago
|
||
Looks like that's a bug in the initial landing of that code in bug 592943.
Component: Developer Tools: Framework → XPCOM
Product: Firefox → Core
|
|
||
Updated•8 years ago
|
Component: XPCOM → XUL
|
||
Comment 7•8 years ago
|
||
Comment on attachment 8770138 [details] [diff] [review] Fix XULPrototypeCache typo Ouch. r=me, but watch out for regressions from us now using the cache in situations where we didn't use to!
Attachment #8770138 -
Flags: review?(bzbarsky) → review+
|
|
||
Comment 9•8 years ago
|
||
Let's see if a more global try highlights any regression.
|
|
||
Comment 10•8 years ago
|
||
Are devtools tests known to be that orange on Windows 7 VM builds?? Otherwise try looks good.
|
|
||
Comment 12•8 years ago
|
||
Still fails after rebase. Looking at test logs, it looks like it introduce a crash. It seems to only happen on Windows 7 VM for unknown reasons... Here is the stack for the crash on: devtools/client/inspector/rules/test/browser_rules_colorpicker-and-image-tooltip_01.js 22:26:37 INFO - 0 VCRUNTIME140.dll!memcpy [memcpy.asm : 194 + 0x0] 22:26:37 INFO - eip = 0x74a4d74e esp = 0x0030f1b0 ebp = 0x0030f1cc ebx = 0x00000100 22:26:37 INFO - esi = 0x21c76000 edi = 0x285cdd50 eax = 0x21c760b0 ecx = 0x000000b0 22:26:37 INFO - edx = 0x00000100 efl = 0x00210203 22:26:37 INFO - Found by: given as instruction pointer in context 22:26:37 INFO - 1 xul.dll!NS_CopySegmentToBuffer(nsIInputStream *,void *,char const *,unsigned int,unsigned int,unsigned int *) [nsStreamUtils.cpp:a62b7bac424b : 820 + 0x14] 22:26:37 INFO - eip = 0x611dbc28 esp = 0x0030f1bc ebp = 0x0030f1cc 22:26:37 INFO - Found by: call frame info 22:26:37 INFO - 2 xul.dll!nsStorageInputStream::ReadSegments(nsresult (*)(nsIInputStream *,void *,char const *,unsigned int,unsigned int,unsigned int *),void *,unsigned int,unsigned int *) [nsStorageStream.cpp:a62b7bac424b : 471 + 0x13] 22:26:37 INFO - eip = 0x611dd0f2 esp = 0x0030f1d4 ebp = 0x0030f1f8 22:26:37 INFO - Found by: call frame info 22:26:37 INFO - 3 xul.dll!nsStorageInputStream::Read(char *,unsigned int,unsigned int *) [nsStorageStream.cpp:a62b7bac424b : 428 + 0x16] 22:26:37 INFO - eip = 0x611dcd75 esp = 0x0030f200 ebp = 0x0030f214 22:26:37 INFO - Found by: call frame info 22:26:37 INFO - 4 xul.dll!mozilla::scache::NewBufferFromStorageStream(nsIStorageStream *,mozilla::UniquePtr<char [0],mozilla::DefaultDelete<char [0]> > *,unsigned int *) [StartupCacheUtils.cpp:a62b7bac424b : 94 + 0x14] 22:26:37 INFO - eip = 0x62794eca esp = 0x0030f21c ebp = 0x0030f248 22:26:37 INFO - Found by: call frame info 22:26:37 INFO - 5 xul.dll!nsXULPrototypeCache::FinishOutputStream(nsIURI *) [nsXULPrototypeCache.cpp:a62b7bac424b : 407 + 0xb] 22:26:37 INFO - eip = 0x621a7d9a esp = 0x0030f250 ebp = 0x0030f2dc 22:26:37 INFO - Found by: call frame info 22:26:37 INFO - 6 xul.dll!nsXULPrototypeCache::WritePrototype(nsXULPrototypeDocument *) [nsXULPrototypeCache.cpp:a62b7bac424b : 327 + 0x9] 22:26:37 INFO - eip = 0x621b3e8d esp = 0x0030f2e4 ebp = 0x0030f2fc 22:26:37 INFO - Found by: call frame info 22:26:37 INFO - 7 xul.dll!mozilla::dom::XULDocument::EndLoad() [XULDocument.cpp:a62b7bac424b : 506 + 0xd] 22:26:37 INFO - eip = 0x621a753e esp = 0x0030f304 ebp = 0x0030f380 22:26:37 INFO - Found by: call frame info I'm leaving for PTO and get back on 1st of August, so do not hesitate to find another owner for this bug.
|
|
Reporter | |
Comment 14•8 years ago
|
||
Alexandre, any chance you can take a look at this again?
Flags: needinfo?(poirot.alex)
|
|
||
Comment 17•8 years ago
|
||
Still fails on the Windows VM. Not really handy to debug, especially given that's not really my area. It would be significantly easier if I can repro on linux at least...
|
|
||
Comment 19•8 years ago
|
||
FinishOutputStream seems to be called only for a couple of devtools resources served from chrome://. bug 1311541 is going to convert some to be served from resource://. I'm wondering if that can workaround this crash. It looks like it is a race as it doesn't crash on comment 18 try push where I added printfs.
|
|
Reporter | |
Comment 20•8 years ago
|
||
Interestingly that crash looks a lot like a top crasher I saw the other day. I'll see if I can track it down.
|
|
Reporter | |
Comment 22•8 years ago
|
||
(In reply to Eric Rahm [:erahm] from comment #20) > Interestingly that crash looks a lot like a top crasher I saw the other day. > I'll see if I can track it down. Thinking of bug 1294533, perhaps this makes it more frequent?
|
|
||
Comment 23•8 years ago
|
||
At least it highlights a reproducible crash in it on windows-vm on try...
Flags: needinfo?(poirot.alex)
|
|
||
Comment 24•8 years ago
|
||
comment 21 try push seems to say either it has been fixed in a very recent changeset (unlikely), or a very simple printf added in FinishOutputStream make the crash go away: +++ b/dom/xul/nsXULPrototypeCache.cpp bool found = mOutputStreamTable.Get(uri, getter_AddRefs(storageStream)); if (!found) return NS_ERROR_UNEXPECTED; + nsAutoCString sp; + uri->GetSpec(sp); + printf("FinishOutputStream(%s, %p)\n", sp.get(), (void*)storageStream);
|
||
Comment 25•7 years ago
|
||
Now that bug 1294533 has been fixed, perhaps the crash has gone away?
|
|
||
Comment 27•7 years ago
|
||
Thanks for the mention, but it still crashes: 16:21:27 INFO - 1 xul.dll!NS_CopySegmentToBuffer(nsIInputStream *,void *,char const *,unsigned int,unsigned int,unsigned int *) [nsStreamUtils.cpp:c50846c4bf89 : 820 + 0x14] 16:21:27 INFO - eip = 0x5ecdf6b0 esp = 0x0029f02c ebp = 0x0029f03c 16:21:27 INFO - Found by: call frame info 16:21:27 INFO - 2 xul.dll!nsStorageInputStream::ReadSegments(nsresult (*)(nsIInputStream *,void *,char const *,unsigned int,unsigned int,unsigned int *),void *,unsigned int,unsigned int *) [nsStorageStream.cpp:c50846c4bf89 : 473 + 0x13] 16:21:27 INFO - eip = 0x5ece0c5f esp = 0x0029f044 ebp = 0x0029f068 16:21:27 INFO - Found by: call frame info 16:21:27 INFO - 3 xul.dll!nsStorageInputStream::Read(char *,unsigned int,unsigned int *) [nsStorageStream.cpp:c50846c4bf89 : 430 + 0x16] 16:21:27 INFO - eip = 0x5ece08dc esp = 0x0029f070 ebp = 0x0029f084 16:21:27 INFO - Found by: call frame info 16:21:27 INFO - 4 xul.dll!mozilla::scache::NewBufferFromStorageStream(nsIStorageStream *,mozilla::UniquePtr<char [0],mozilla::DefaultDelete<char [0]> > *,unsigned int *) [StartupCacheUtils.cpp:c50846c4bf89 : 94 + 0x14] 16:21:27 INFO - eip = 0x601db1d1 esp = 0x0029f08c ebp = 0x0029f0b8 16:21:27 INFO - Found by: call frame info 16:21:27 INFO - 5 xul.dll!nsXULPrototypeCache::FinishOutputStream(nsIURI *) [nsXULPrototypeCache.cpp:c50846c4bf89 : 407 + 0xb] 16:21:27 INFO - eip = 0x5fba897d esp = 0x0029f0c0 ebp = 0x0029f14c 16:21:27 INFO - Found by: call frame info 16:21:27 INFO - 6 xul.dll!nsXULPrototypeCache::WritePrototype(nsXULPrototypeDocument *) [nsXULPrototypeCache.cpp:c50846c4bf89 : 327 + 0x9] 16:21:27 INFO - eip = 0x5fbb42a4 esp = 0x0029f154 ebp = 0x0029f16c 16:21:27 INFO - Found by: call frame info 16:21:27 INFO - 7 xul.dll!mozilla::dom::XULDocument::EndLoad() [XULDocument.cpp:c50846c4bf89 : 506 + 0xd] 16:21:27 INFO - eip = 0x5fba8025 esp = 0x0029f174 ebp = 0x0029f1f0 16:21:27 INFO - Found by: call frame info 16:21:27 INFO - 8 xul.dll!XULContentSinkImpl::DidBuildModel(bool) [nsXULContentSink.cpp:c50846c4bf89 : 228 + 0xa] 16:21:27 INFO - eip = 0x5fba79a5 esp = 0x0029f1f8 ebp = 0x0029f20c 16:21:27 INFO - Found by: call frame info 16:21:27 INFO - 9 xul.dll!nsParser::DidBuildModel(nsresult) [nsParser.cpp:c50846c4bf89 : 900 + 0xe] 16:21:27 INFO - eip = 0x5f19d04f esp = 0x0029f214 ebp = 0x0029f224 16:21:27 INFO - Found by: call frame info 16:21:27 INFO - 10 xul.dll!nsParser::ResumeParse(bool,bool,bool) [nsParser.cpp:c50846c4bf89 : 1507 + 0xa] 16:21:27 INFO - eip = 0x5f1a00ed esp = 0x0029f22c ebp = 0x0029f244 16:21:27 INFO - Found by: call frame info 16:21:27 INFO - 11 xul.dll!nsParser::OnStopRequest(nsIRequest *,nsISupports *,nsresult) [nsParser.cpp:c50846c4bf89 : 1880 + 0xe] 16:21:27 INFO - eip = 0x5f19ebc9 esp = 0x0029f24c ebp = 0x0029f264 16:21:27 INFO - Found by: call frame info 16:21:27 INFO - 12 xul.dll!nsJARChannel::OnStopRequest(nsIRequest *,nsISupports *,nsresult) [nsJARChannel.cpp:c50846c4bf89 : 1019 + 0xe]
From :smaug's testing, it seems like the typo this bug is trying to fix may only affect the prototype cache the first time a document is used. The in memory cache appears to still be correctly used for subsequent loads of the same document. (Adding this mostly so I don't forget what's impacted here.)
|
||
Comment 29•6 years ago
|
||
The typo was removed in bug 1404198, the crash is still in the comment in prototype cache.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•