51384 - Crash when navigating (deprecated?) relative URL's

Status: RESOLVED WORKSFORME

Description

[Randell Jesup [:jesup]]

FreeBSD 4.1 20000905xx (noon EDT)
Crashes fairly consistently when navigating around the bug-test page for bug 50629.

Got to the URL.  Click on "A http:/RFC link".  Hit Back after you get to the
netscape search page.  Click on "A /RFC/ link".  Boom (usually).

The crash _appears_ to be occuring in nsWindow::UpdateIdle, perhaps in a
pure_virtual call.

2 stack backtraces to be appended.

Comment 1

[Randell Jesup [:jesup]]

Created attachment 14035 [details]
2 stack backtraces

Comment 2

[John Morrison]

Can't reproduce this crash on a build pulled ~2am last night (rh6.1 using gtk).

The stack traces, though, indicate that you are building with the xlib version
os nsWindow.cpp. pavlov says that [e-mail] is one of the people 
working on this. -> [e-mail]

Comment 3

[Stuart Parmenter]

erk, these arn't xlib stack traces.  reassigning to blizzard, I'll take a look
at this

Comment 4

[John Morrison]

Sorry, I was focussing on the line number in nsWindow.cpp, which must be 
the xlib version (unless there is some confusion in the debugger dealing 
with the symbols). [I should have made my question clearer ...]

Comment 5

[Randell Jesup [:jesup]]

Sorry, the line numbers (at least) are horked.  Ever since I upgraded to FreeBSD
4.1 last week, GDB gives me bogus line numbers (and no arguments) for shared
libs.  Weird.  I _think_ the function names are good.  (Yes, I did a full
clobber build after upgrading).  This BSD thing happens to others too.

Comment 6

[Randell Jesup [:jesup]]

Nominating for nsbeta3.  Crashes repeatably for me.  We need confirmation it's
a problem with other platforms (or possibly a pull-while-tree-is-open issue).

More info on repeatability - I clicked on these links, waited until something
appears, click Back, try another one of them.  After 2-7 visits of links on that
page, it crashes.

Comment 7

[David Evola]

URL now "Not Found"

Comment 8

[Scott Gifford (old account)]

I just bumped into a very similar stack trace while looking at bug 65800 and bug
61386.  I'm going to see if I can trace it any further, but this seems to still
be an issue.  This is from a nightly build from 1/19/2001, with the patches from
the two previously mentioned bugs.

Comment 9

[Scott Gifford (old account)]

Created attachment 23124 [details]
Similar stack trace

Comment 10

[Scott Gifford (old account)]

The procedure I followed to get this bug is the one in bug 66164.  This is
completely different from the way that this bug was triggered initially (via
relative URLs).  I don't know if relative URLs still crash.

Comment 11

[Scott Gifford (old account)]

After updating to a CVS version from 1/22/2001 and applying the patches from bug
61386 and bug 61756, I no longer get this crash following the procedure
documented in bug 66164.

People still seeing this bug might want to try these patches, and see if that
makes it go away.

Comment 12

[Scott Gifford (old account)]

The patches that fixed this for me have all landed.  Somebody with more
knowledge of this bug than me (I have never been able to reproduce it) might
want to see if they can reproduce it, and go ahead and close it out...

Comment 13

[Olivier Cahagne]

404, no testcase, 'http:/' links are covered by another bug report.

Comment 14

[Scott Gifford (old account)]

I haven't experienced anything similar to this bug in nearly a year, and no
additional stack traces have been attached, and nothing's been marked as a
duplicate of this in over a year.  Further, none of the examples (like visiting
an http:/ link) seem to trigger it anymore.

I think that somebody with the ability can probably safely close this bug out as
WORKSFORME.

Comment 15

[Christopher Blizzard (:blizzard)]

Works for me, too.