Closed Bug 11625 Opened 21 years ago Closed 21 years ago

Crash opening template-example-menu.xul

Categories

(Core Graveyard :: RDF, defect, P3)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: shaver, Assigned: waterson)

References

()

Details

#0  0x48bc4233 in nsCOMPtr<nsINameSpaceManager>::assign_with_AddRef (
    this=0x48a45b20, rawPtr=0x40116408) at ../../../dist/include/nsCOMPtr.h:646
#1  0x48bc4791 in nsCOMPtr<nsINameSpaceManager>::operator= (this=0x48a45b20,
    rhs=@0xbffff208) at ../../../dist/include/nsCOMPtr.h:581
#2  0x48b540d6 in RDFContentSinkImpl::Init (this=0x48a45b08, aURL=0xbffff380,
    aNameSpaceManager=0x40116408) at nsRDFContentSink.cpp:754
#3  0x400ff7f5 in CViewSourceHTML::WillBuildModel (this=0x49140590,
    aFilename=@0x48a45fb0, aNotifySink=1, aSourceType=@0x48a46140,
    aSink=0x48a45b08) at nsViewSourceHTML.cpp:357
#4  0x400f558e in nsParser::WillBuildModel (this=0x48a45cc0,
    aFilename=@0x48a45fb0, aDefaultDTD=0x0) at nsParser.cpp:502

Kills both viewer and apprunner dead.  Getting a stack trace out of apprunner
requires more heavy use of drugs than I can perform 6 hours before an
international flight, but I'm sure it's the same thing.
Interestingly, I can load -tree.xul from www.mozilla.org, but if I load it from
localhost via HTTP I get the above crash.

If I load -menu.xul from mozilla.org, it gives me a black screen, but locaing
from http://localhost/ crashes as above.  Weird.

(These tests with viewer.)
Blocks: 11413
Status: NEW → ASSIGNED
Target Milestone: M10
This seems to work for me (right now, with the instructions you've given). I'm wondering if its a mimetype mapping problem. I just checked www.mozilla.org, and it is in fact transferring data as "text/xul". Is your machine doing that? We definitely shouldn't _crash_ if the mimetype mapping is wrong. Lemme go try that...
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Poked around this a bit more. Seems like the original XUL file had an extra '>'
at the end of the first line: this may have been causing the parser to barf.
_That_ seems fixed now. I tried sending back the data with 'text/plain' and
that works too. Finally, I updated the example to be "fixed", and the tree
example works, but the "menu" example doesn't, probably because it doesn't want
to create menu frames in a content area. Marking as "WORKSFORME".
Status: RESOLVED → VERIFIED
marking as verified, no crash
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.