Daniel Holbert [:dholbert] Reporter
	Description • 8 years ago

In bug 1304197, we investigated some spammy warnings like the following in our test runs:
> WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80520012: file layout/style/Loader.cpp, line 2157

However, I cannot reproduce this warning when running the same test locally. Instead, I get this (more-helpful) warning, which isn't present in the TreeHerder logs:
{
Chrome file doesn't exist: /scratch/work/builds/mozilla-inbound/obj/dist/bin/browser/chrome/devtools/content/inspector/markup/markup.css
}

(That warning doesn't happen anymore now that bug 1305568 has removed a bogus stylesheet reference, but it should be possible to bring it back by reverting that bug's patch.)

Filing this bug to investigate why we're logging differently here (and, once we know that, perhaps to see if we can make the NS_ENSURE_SUCCESS log message more useful, maybe at a lower level in the stack).

I suspect it might have to do with packaging (since IIUC the test runners are running a packaged build & I'm not), though I'm not sure.

	:Gijs (he/him)
	Comment 1 • 8 years ago

(In reply to Daniel Holbert [:dholbert] from comment #0)
> I suspect it might have to do with packaging (since IIUC the test runners
> are running a packaged build & I'm not), though I'm not sure.

I was thinking the same. It should be easy to test this locally if you have a debug build already (I don't...): run ./mach package and then

./mach mochitest path/to/test --appname dist

("dist" is a magic alias rather than passing the full path to an executable; the test framework should resolve it to the packaged app)

	Daniel Holbert [:dholbert] Reporter
	Comment 2 • 8 years ago

Yup, thanks -- that gives me the NS_ENSURE_SUCCESS logging that the releng machines have, instead of the "Chrome file doesn't exist" logging that I had previously.

Unfortunately, it also prevents gdb from being effective (I think it can't find symbols for the packaged build), so I can't immediately/easily poke around and investigate the NS_ENSURE_SUCCESS failure to find out why behavior is different.

	Julien Cristau [:jcristau]
	Comment 3 • 7 years ago

Too late for firefox 52, mass-wontfix.