Closed Bug 51384 Opened 25 years ago Closed 23 years ago

Crash when navigating (deprecated?) relative URL's

Categories

(Core :: XUL, defect, P3)

x86
FreeBSD
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jesup, Assigned: blizzard)

References

()

Details

(Keywords: crash)

Attachments

(2 files)

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.
Keywords: crash
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 quy@igelaus.com.au is one of the people working on this. -> quy@igelaus.com.au
Assignee: trudelle → quy
erk, these arn't xlib stack traces. reassigning to blizzard, I'll take a look at this
Assignee: quy → blizzard
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 ...]
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.
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.
Keywords: nsbeta3, qawanted
URL now "Not Found"
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.
Blocks: 66164
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.
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.
No longer blocks: 66164
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...
404, no testcase, 'http:/' links are covered by another bug report.
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.
Works for me, too.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: