btek on testerbox turned orange at about 7:50am this morning; the people on the hook are karnaze, dbradley, brade, ccarlen, and rjesup.

Below is the test output. This tinderbox creates a clean profile using the -CreateProfile option. This appears to be happening successfully. It then starts the browser and runs through the page load tests. Each URL should print out as a separate line; I'm not seeing any, so it's either crashing or hanging on startup. ---------------------------------- mozilla-bin binary exists, build successful. Begin: Thu Nov 1 12:22:19 2001 cmd = /export/tinderbox/Linux_2.2.14-5.0smp_Depend/mozilla//dist/bin/mozilla-bin -CreateProfile tinderbox End: Thu Nov 1 12:22:24 2001 cmd = sync; sleep 10 Running LayoutPerformanceTest ... Begin: Thu Nov 1 12:22:37 2001 cmd = /export/tinderbox/Linux_2.2.14-5.0smp_Depend/mozilla//dist/bin/mozilla-bin -P tinderbox "http://localhost/page-loader/loader.pl?delay=1000&nocache=0&maxcyc=4&timeout=30000" End: Thu Nov 1 12:22:39 2001 ----------- Output from LayoutPerformanceTest ------------- ProfileName : tinderbox ----------- End Output from LayoutPerformanceTest ---------

FWIW jrgm's page load tests work on my debug Win32 build that I checked in from. My changes dealt with DOM/XPConnect exception handling.

ditto for me.

On the linux build that I used to test this before checkin, it runs the page loader. I tried on a new profile and an existing one.

Well, fsck it. I can't get my debug build to show any problems either. I'll just kick the tinderbox and hope it works. Clearing blocker status.

It's crashing in xptiInterfaceInfo::ResolveLocked(). (gdb) bt 10 #0 0x40142e8e in xptiInterfaceInfo::ResolveLocked () from /export/tinderbox/Linux_2.2.14-5.0smp_Depend/mozilla/dist/bin/./libxpcom.so #1 0x40142de2 in xptiInterfaceInfo::Resolve () from /export/tinderbox/Linux_2.2.14-5.0smp_Depend/mozilla/dist/bin/./libxpcom.so #2 0x40143351 in xptiInterfaceInfo::GetConstantCount () from /export/tinderbox/Linux_2.2.14-5.0smp_Depend/mozilla/dist/bin/./libxpcom.so #3 0x40c60fe7 in nsScriptNameSpaceManager::FillHashWithDOMInterfaces () from /export/tinderbox/Linux_2.2.14-5.0smp_Depend/mozilla/dist/bin/components/libjsdom.so #4 0x40c613a1 in nsScriptNameSpaceManager::Init () from /export/tinderbox/Linux_2.2.14-5.0smp_Depend/mozilla/dist/bin/components/libjsdom.so #5 0x40c64d9d in nsJSContext::InitContext () from /export/tinderbox/Linux_2.2.14-5.0smp_Depend/mozilla/dist/bin/components/libjsdom.so #6 0x40c65c4e in NS_CreateScriptContext () from /export/tinderbox/Linux_2.2.14-5.0smp_Depend/mozilla/dist/bin/components/libjsdom.so #7 0x40c60443 in nsDOMSOFactory::NewScriptContext () from /export/tinderbox/Linux_2.2.14-5.0smp_Depend/mozilla/dist/bin/components/libjsdom.so #8 0x40c1c35c in nsDocShell::EnsureScriptEnvironment () from /export/tinderbox/Linux_2.2.14-5.0smp_Depend/mozilla/dist/bin/components/libdocshell.so #9 0x40c1d61e in nsWebShell::GetInterface () from /export/tinderbox/Linux_2.2.14-5.0smp_Depend/mozilla/dist/bin/components/libdocshell.so

Maybe related, maybe not: I had a weird crash on my Mac in xptiInterfaceInfo. Removing Component Registry and xpti.dat fixed it. I can't reproduce it, running again with the old Component Registry and xpti.dat seems to work fine now.

Yes, it looks like it was reading the interface info and it might be corrupted. While my patch contained some DOM changes, on the surface at least it doesn't appear to cross paths with this stack trace.

My patched removed nsIDOMNSDOMException interface. Could there have been some artifact from a previous build that trip this up?

I tried removing components.reg, but not xpti.dat. The distclean build looks like it's running the tests properly now...

Yeah, that's probably it. Clobbering the build worked (although I probably just needed to get rid of some of the typelibs).

Reopening and assigning to me. It still should not crash when it can't find an interface info that is listed in xpti.dat. I spoke with jst about what the DOM is up to here in enumerating these interfaces. I have a patch that will make xpti fail more gracefully if this ever comes up again. And it also makes the DOM not bail if this happens.

mine

more appropriate summary

Comment on attachment 56210 [details] [diff] [review] proposed fix. ready for review. sr=brendan@mozilla.org

Comment on attachment 56210 [details] [diff] [review] proposed fix. ready for review. r=jst

fix checked in. Thanks.