Actually, here's the top of the stack trace (not an attachment): #0 0x40321b79 in nsSimpleCharString::operator= () #1 0x40323560 in nsFilePath::nsFilePath () #2 0x403237eb in nsFileSpec::nsFileSpec () #3 0x40b85a6e in RDFXMLDataSourceImpl::Flush () #4 0x4033997a in XPTC_InvokeByIndex () #5 0x40b2f676 in nsXPCWrappedNativeClass::CallWrappedMethod () #6 0x40b30230 in WrappedNative_CallMethod () #7 0x402b62a2 in js_Invoke () #8 0x402bbf3e in js_Interpret () #9 0x402b6651 in js_Execute () #10 0x402a120f in JS_EvaluateUCScriptForPrincipals () #11 0x401087e3 in nsJSContext::EvaluateString () #12 0x409f9301 in HTMLContentSink::EvaluateScript () #13 0x409f973d in HTMLContentSink::ProcessSCRIPTTag ()
Fixed. Update mozilla/rdf/base/src/nsRDFXMLDataSource.cpp (depending on how up-to-date your tree is, you may need to pull more).
Verified fixed. No longer crashes.
It turns out the nsFileSpec's Unix 'file:' URL parsing is brain-dead. Instead of doing "file:/u/whatever", do "file:///u/whatever". (That is, three slashes instead of one.) I'm going to switch RDF over to using all of the necko parsing stuff as soon as it lands, so let's leave the bug closed.
waterson: do you know if anything will still be using the old nsFileSpec/nsFilePath code after Necko lands? If so, this bug should probably be reopened (and assigned to someone else) so that it can be fixed. Much or all of the code that depends on kFileURLPrefix and kFileURLPrefixLength  could cause problems on Unix with whatever uses that code.  defined in http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsFileSpec.h#157 and used in http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsFileSpec.cpp
I hope to use the new APIs when they become official. I'm just going to try to open an output channel (not sure if that's the right lingo) on whatever the URL is that I have.
I'm not just worried about your use - I'm worred that someone else might still be using nsFileSpec and have similar problems... or will nsFileSpec disappear after Necko lands?