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.
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 firstname.lastname@example.org is one of the people working on this. -> email@example.com
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.
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.
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
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.