XUL page does not load (previously crashed)

VERIFIED WORKSFORME

Status

()

Core
XML
P3
major
VERIFIED WORKSFORME
18 years ago
17 years ago

People

(Reporter: Mathieu Fenniak, Assigned: Gagan)

Tracking

({crash, regression})

Trunk
Future
x86
All
crash, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2-], URL)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
Ever since finding out how to add things to my sidebar, I've been doing just

that. The given URL is a new XML page I've been creating with the hopes of

making it a search tool similar to the included Mozilla search panel, but for a

specific web site, moo.ca. The page is viewable now in M15, and it's very little

currently to look at, but the 2000/05/21 daily crashes on it consistantly. This

is the only output that's related on the console:



nsXMLContentSink::AddDocTypeDecl

.//run-mozilla.sh: line 29: 21390 Segmentation fault      $prog ${1+"$@"}

Comment 1

18 years ago
Build 2000-05-19-08 Win Talkback running on Windows 98 crashes when attempting 
to display the above URL. (Talkback sent 21 May 22:00 pacific time.)
Build 2000-05-11-08 Win talkback running on Windows 98 does NOT crash when 
displaying the above URL.
Suggest STATUS: NEW, PLATFORM: ALL, KEYWORD: CRASH, REGRESSION

Comment 2

18 years ago
Adding crash keyword
Keywords: crash

Comment 3

18 years ago
Created attachment 9285 [details]
stack trace, PC/Linux, built from 5/21 sources

Comment 4

18 years ago
This seems to be an endless loop in nsXULElement::GetContainingNameSpace:

#0     nsIStyledContent::GetIID ()               from librdf.so
#1     nsQueryInterface::operator() ()           from libxpcom.so
#2     nsCOMPtr_base::assign_from_helper ()      from libxpcom.so
#3     nsXULElement::GetContainingNameSpace ()   from librdf.so
[...]
#32536 nsXULElement::GetContainingNameSpace ()   from librdf.so
#32537 nsXULElement::GetNameSpacePrefixFromId () from librdf.so
#32538 nsXULElement::SetAttribute ()             from librdf.so
#32539 nsXMLContentSink::AddAttributes ()        from libraptorhtml.so
#32540 nsXMLContentSink::OpenContainer ()        from libraptorhtml.so
#32541 CWellFormedDTD::HandleStartToken ()       from libraptorhtmlpars.so
#32542 CWellFormedDTD::HandleToken ()            from libraptorhtmlpars.so
#32543 CWellFormedDTD::BuildModel ()             from libraptorhtmlpars.so
#32544 nsParser::BuildModel ()                   from libraptorhtmlpars.so

Confirming bug, OS=All, severity=critical, regression kw.
The 5/27 build crashes, too.
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
OS: Linux → All

Comment 5

18 years ago
I tried this today using yesterday's NT debug build.  The crash no longer 
happens, but, the page does not display at all.  Removing crash keyword and 
updating summary.
Keywords: crash
Summary: XML document causes crash → XML document does not display

Comment 6

18 years ago
When I go to this url using Mozilla, I get the following message in the content 
area of the browser: "Redirection error: Infinite loop detected".

The Necko guys need to investigate this further.  Re-assigning to Gagan...
Assignee: nisheeth → gagan
Summary: XML document does not display → "Redirection error: Infinite loop detected" on above url

Comment 7

18 years ago
I also see this error message when going to: http://javascript.com

Then clicking on: Popup Window Maker

Or any of the main article links that point to: http://redir.internet.com/*

Possibly related to bug 42353

Comment 8

18 years ago
*** Bug 43234 has been marked as a duplicate of this bug. ***

Comment 9

18 years ago
*** Bug 43447 has been marked as a duplicate of this bug. ***

Comment 10

18 years ago
I have the same problem going to http://www.distributed.net and clicking on 
their .plans link. (actual address 
http://n0cgi.distributed.net/cgi/dnet-finger.cgi) My new URL address in my 
address bar is 
file:///C:/ZIPTEMP/MOZILLA/BIN/chrome/packages/core/necko/content/redirect_loop.
xul after clicking in

I'm running build 2000062308 on win98

Comment 11

18 years ago
*** Bug 43636 has been marked as a duplicate of this bug. ***

Comment 12

18 years ago
*** Bug 42353 has been marked as a duplicate of this bug. ***

Comment 13

18 years ago
I cannot seem to reproduce the bug in todays build (id: 2000062408.) Mark bug as
resolved or leave as new?
(Reporter)

Comment 14

18 years ago
No. Original bug still exists. The redirection error is gone, but the page still
does not load for me with today's build (2000062408).

Comment 15

18 years ago
Yeah, but thats a totally different bug than the one stated here. I don't know
how bugzilla works (brand new at this) but when we close this bug, wouldn't that
close the duplicates? Because the problem with the page loading up has nothing
to do with what is stated in the summary. So your current problem with loading
the URL could be overlooked when they do a test. Makes sense doesn't it?
(Reporter)

Comment 16

18 years ago
Nisheeth Ranjan renamed this bug on June 16th when another bug (which has now
been fixed) made the page impossible to get to. Now the bug that I originally
reported still exists, the page does not load.
Severity: critical → major
Summary: "Redirection error: Infinite loop detected" on above url → XUL page does not load (previously crashed)

Comment 17

18 years ago
*** Bug 43783 has been marked as a duplicate of this bug. ***

Comment 18

18 years ago
Add crash keyword to open crashers.
Keywords: crash
(Assignee)

Comment 19

18 years ago
ruslan: these seem to be some edge cases of your check for redirect-loops. 
Assignee: gagan → ruslan
(Assignee)

Updated

18 years ago
Keywords: nsbeta2

Comment 20

18 years ago
No. The redirect is fixed. All pages in this bug except for the sidebar would 
load. Sending back.
Assignee: ruslan → jenkins

Comment 21

18 years ago
Putting on [nsbeta2-] radar. Not critical to beta2. 
Whiteboard: [nsbeta2-]

Comment 22

18 years ago
uhmm, wth.... did I do something to get assigned to this bug? =c( (i must be dense)

Comment 23

18 years ago
Gagan, can I assign this to you? I must have done something stupid to have it
assigned to me.

Comment 24

18 years ago
I still don't know how this happened but I'm reassigning but to owner of
selected component. My limits in C++ are defining classes and recursion. Heck, I
never used a pointer before!!!!!! I hope I didn't mess anything up.
Assignee: jenkins → nisheeth
QA Contact: chrisd → petersen

Comment 25

18 years ago
Re-assigning to Gagan because the original "page does not load" problem is back.  
Assignee: nisheeth → gagan
(Assignee)

Updated

18 years ago
Target Milestone: --- → Future

Comment 26

17 years ago
It seems to me it's WORKSFORME now. (Linux nightly 20000926 from trunk)

Comment 27

17 years ago
This is definitely not working yet. In fact, I've seen it twice today (first
times in a long time.) To duplicate it: go to
http://www.dulug.duke.edu/~mark/getting-started-links.html
click on the third link on the page:
http://www.debian.org/~bortz/SGML-HOWTO/potato/howto.html
You should get this in your URL bar:
file:///home/louie/package/chrome/packages/core/redirect_loop.xul
So, please don't mark WFM.


Comment 28

17 years ago
Hmmm I don't understand how it's connected to original error. This is completely
different bug. Mozilla doesn't issue a message that the file doesn't exist. And
there is another bug that the file redirect_loop.xul is in a different directory
(chrome/comm/content/necko/redirect_loop.xul). If you put that path into the URL
bar mozilla loads the file fine.

Comment 29

17 years ago
I think that this bug may have disappeared- I can't duplicate it on any of the
test cases linked to from here, nor can I dup it from similar testcases in a
couple of related bugs. I think we should mark as WFM- any objections?

Comment 30

17 years ago
Marking WORKSFORME.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 31

17 years ago
VERIFIED WFM linux 2001062021
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.