Status

()

Core
RDF
P3
critical
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: dbaron, Assigned: Chris Waterson)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
Flush() crashes 100% of the time for me (accessed through JavaScript on an
RDFDataSource) on Linux (tested opt (June 30) and debug (July 2) builds in
viewer).  As long as I modify the datasource, it crashes.  (If I don't modify
the datasource, it doesn't.)

I'll attach a stack trace from an opt build, whatever that's worth (I don't have
enough memory to debug a debug build), and a (relatively) simplified version of
a page to cause the crash.  To replicate the crash, you'll have to download the
pages (RDF and HTML) and change the URL in the script in the HTML file (the
original was XUL, but the simplified version is in HTML).
(Reporter)

Comment 1

19 years ago
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 ()
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M9
(Reporter)

Comment 2

19 years ago
Created attachment 674 [details]
RDF file
(Reporter)

Comment 3

19 years ago
Created attachment 675 [details]
HTML file with JavaScript (must download - see comments)
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 4

19 years ago
Fixed. Update mozilla/rdf/base/src/nsRDFXMLDataSource.cpp (depending on how
up-to-date your tree is, you may need to pull more).
(Reporter)

Updated

19 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 5

19 years ago
Verified fixed.  No longer crashes.
(Assignee)

Comment 6

19 years ago
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.
(Reporter)

Comment 7

19 years ago
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 [1] could
cause problems on Unix with whatever uses that code.

[1] 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
(Assignee)

Comment 8

19 years ago
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.
(Reporter)

Comment 9

19 years ago
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?
You need to log in before you can comment on or make changes to this bug.