> 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

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

Thanks for the bisection. Yes, it looks like XUL doesn't like to be hosted on a about: page.

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?

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?

Looks like that's a bug in the initial landing of that code in bug 592943.

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!

Let's see if a more global try highlights any regression.

Are devtools tests known to be that orange on Windows 7 VM builds?? Otherwise try looks good.

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.

Alexandre, any chance you can take a look at this again?

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...

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.

Interestingly that crash looks a lot like a top crasher I saw the other day. I'll see if I can track it down.

(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?

At least it highlights a reproducible crash in it on windows-vm on try...

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);

Now that bug 1294533 has been fixed, perhaps the crash has gone away?

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.)

The typo was removed in bug 1404198, the crash is still in the comment in prototype cache.