Closed Bug 126569 Opened 23 years ago Closed 23 years ago

application fault (exception) when clicking on a link

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: urifrid, Assigned: asa)

Details

(Keywords: crash)

after downloading the latest nightly build (2/20/2002), i've found that when clicking on a link that opens a new navigator window, mozilla crashes with a "application fault, can't read 0x000000. Memory can't be read". this happens in several pages and only in win2k so far. Linux seems to be ok. looks like you are losing a pointer to a buffer or the buffer is too small.
If you are crashing in Mozilla the best thing you can do to help the developers fix your bug is to attach a stacktrace. If you're not building yourself you are not out of luck. Mozilla releases nightly and milestone builds with Full Circle's Talkback (you can get latest build on: http://ftp.mozilla.org/pub/mozilla/nightly/latest/) Talkback should catch most crashes and offer to send in a crash report. Developers can retrieve that crash report and attach it to your bug report if you provide either the Incident ID (you can get it by running the talkback program from /components/talkback/). Thanks for your help in testing Mozilla and reporting bugs.
Severity: normal → critical
Keywords: crash
ok, but is talkback on the nightly builds? i mean i downloaded this morning (2/20/2002 build 2002021915) the latest and installe dover the previous installation. the program just crashes with any signal of catching anything... you know the default windoze "exception" message.
@uri: If you use the link provided by Adam you'll find (beside others ;o) ) two zip's named: mozilla-win32-talkback.zip 9.9M mozilla-win32.zip 9.6M The first one is the one of choice - if you install Mozilla make sure that you install talkback, too (I'm not sure whether talkback is installed by default so I suggest using "Custom Installation" and select "Quality Feedback Agent" to make sure talkback gets installed) I also won't recommend to install over previous versions of mozilla - you can delete the program directory and install the newer version into it without loss of bookmarks or personal settings as all personal information gets stored in the mozilla profile which is located in a different directory. To ensure this you can search for your personal bookmark file which should not be located in the program directory!
done. i made sure that talkback is installed... yet it crashes without any signs of catching it... anything else i could try? thanks
Confirming bug on Windows 98, Build ID: 2002021915 (0.9.8+). I've had many crashes that fit the profile, mostly in builds prior to the Feb 20 build. My Talkback ID's are: TB2944376Z, TB3081826M, TB3098949Q, TB3119299E, and TB3124694Q. I firmly believe that all of these Talkback's are caused by the same bug. I'm not sure that this bug is connected to opening a new window. I think this bug is caused by clicking on links. I can't figure out how to reproduce this bug reliably, but I know it happens. Thus, confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mozilla0.9.8
Nominating for Mozilla 0.9.9.
Keywords: mozilla0.9.8 → mozilla0.9.9
I am not sure if this is what I have been experiencing with 2002021508 trunk for MacOS9.x. In Preference|Privacy and Security|Images, I set to accept only the images from the originating server.(don't know if it is relevant) When I try loading http://www.boston.com and then click a news story link before the page has completely loaded, I get a crash > 50% of the time. The stacktrace looks like this: Calling chain using A6/R1 links Back chain ISA Caller 00000000 PPC 3F54EE60 0A6D4200 PPC 3F539638 main+00138 0A6D41A0 PPC 3F538B50 main1(int, char**, nsISupports*)+00AF0 0A6D4020 PPC 3BF57D58 nsAppShellService::Run()+00018 0A6D3FE0 PPC 3BF16068 nsAppShell::Run()+00038 0A6D3FA0 PPC 3BF168CC nsMacMessagePump::DoMessagePump()+0003C 0A6D3F50 PPC 3BF16C38 nsMacMessagePump::DispatchEvent(int, EventRecord*)+00078 0A6D3F10 PPC 3BF16E14 nsMacMessagePump::DoUpdate(EventRecord&)+00094 0A6D3EB0 PPC 3BF17EBC nsMacMessagePump::DispatchOSEventToRaptor(EventRecord&, GrafPort *)+0005C 0A6D3E60 PPC 3BF0F810 nsMacWindow::DispatchEvent(void*, int*)+00030 0A6D3E20 PPC 3BF10B70 nsMacEventHandler::HandleOSEvent(EventRecord&)+00080 0A6D3DD0 PPC 3BF1210C nsMacEventHandler::UpdateEvent()+0001C 0A6D3D90 PPC 3BEFFB84 nsWindow::HandleUpdateEvent(MacRegion**)+00284 0A6D3C80 PPC 3BEFF740 nsWindow::PaintUpdateRect(Rect*, void*)+000E0 0A6D3C10 PPC 3BF0016C nsWindow::UpdateWidget(nsRect&, nsIRenderingContext*)+001AC 0A6D3B60 PPC 3BF0016C nsWindow::UpdateWidget(nsRect&, nsIRenderingContext*)+001AC 0A6D3AB0 PPC 3BF0016C nsWindow::UpdateWidget(nsRect&, nsIRenderingContext*)+001AC 0A6D3A00 PPC 3BF0016C nsWindow::UpdateWidget(nsRect&, nsIRenderingContext*)+001AC 0A6D3950 PPC 3BF0016C nsWindow::UpdateWidget(nsRect&, nsIRenderingContext*)+001AC 0A6D38A0 PPC 3BF00054 nsWindow::UpdateWidget(nsRect&, nsIRenderingContext*)+00094 0A6D37F0 PPC 3BF00EFC nsWindow::DispatchWindowEvent(nsGUIEvent&, nsEventStatus&)+0001C 0A6D37B0 PPC 3BF00DA0 nsWindow::DispatchEvent(nsGUIEvent*, nsEventStatus&)+00090 0A6D3760 PPC 3BADDBA4 HandleEvent(nsGUIEvent*)+00044 0A6D3710 PPC 3BAE7678 nsViewManager::DispatchEvent(nsGUIEvent*, nsEventStatus*)+00258 0A6D35F0 PPC 3BAE43DC nsViewManager::Refresh(nsView*, nsIRenderingContext*, nsIRegion* , unsigned int)+0045C 0A6D3500 PPC 3BAE5BCC nsViewManager::RenderViews(nsView*, nsIRenderingContext&, const nsRect&, int&)+0030C 0A6D3460 PPC 3BAE5DB8 nsViewManager::RenderDisplayListElement(DisplayListElement2*, ns IRenderingContext&)+000C8 0A6D3360 PPC 3BADE374 nsView::Paint(nsIRenderingContext&, const nsRect&, unsigned int, int&)+00074 0A6D3310 PPC 3BB1F498 PresShell::Paint(nsIView*, nsIRenderingContext&, const nsRect&)+ 00088 0A6D32B0 PPC 3BCA0F44 CanvasFrame::Paint(nsIPresContext*, nsIRenderingContext&, const nsRect&, nsFramePaintLayer, unsigned int)+00024 0A6D31A0 PPC 3BB261F0 nsHTMLContainerFrame::Paint(nsIPresContext*, nsIRenderingContext &, const nsRect&, nsFramePaintLayer, unsigned int)+00160 0A6D3110 PPC 3BB341EC nsCSSRendering::PaintBackground(nsIPresContext*, nsIRenderingCon text&, nsIFrame*, const nsRect&, const nsRect&, const nsStyleBorder&, int, int, int)+001AC 0A6D3070 PPC 3BB347DC nsCSSRendering::PaintBackgroundWithSC(nsIPresContext*, nsIRender ingContext&, nsIFrame*, const nsRect&, const nsRect&, const nsStyleBackground&, const nsStyle Border&, int, int, int)+0047C
Oops! My crash above was bug 125713. Sorry for spam.
Hmmm - sounds really spooky... ;o) @uri, Andrew Could this be related to your profiles you're using? Did you check a new one? Bug neither occurs right now - nor did it occur in the past on my system (currently running #2002020908 on NT 4.0) but I know that such kind of crashes could be related to profiles and as mentioned in comment #2 at least uri sometimes installed over a previous version without generating a new profile...
yeah, i tried yesterday, i removed any installations plus i deleted all the profiles in the machine. i re-installed the latest build and created a new profile... nothing... still crashes randomly. i tried this on a win2k and on a red hat 7.2 box, linux seems to be ok, win2k not.
It's random, and doesn't go by URL/URI. That's why I didn't enter anything in the comments or URL/URI line in the Talkbacks. I'll test Mozilla today with a new profile.
new addition to the bug, now in linux (build 2002021906), i tried this so far ONLY on eric raymond's page (www.tuxedo.org/~esr/software.html), you click on a link to download something and it's on, you click again (same link or different one) and mozilla crashes and closes itself, causing all the new bookmanks to disapear.
sorry about the spam... after mozilla crashes in Linux (previous comment) it leaves zombified programs running, they take over all the resourses, i made a ps -ef and i found 6 copies of mozilla running on memory, as soon as i killed them the system returned to normal load
I've been having tons of crashes over the last week. I think now though that my Win 98 system could be turning unstable on me. In particular, my video driver, from ATI, seems to be the problem according to Microsoft's KB (I'm having some "ddhelp" problems.) Still, I think this problem is real. Go to Buzzflash.com and click on 10-12 links in rapid succession, for instance (each opens a new window). In my experience, that = boom.
yeah, it happened in both win2k and RH Linux 7.2, any site where you click more than one link the second link you click crashes Mozilla. the debugger doesn't catch the error.
Just to make sure I tried http://www.buzzflash.com given by Andrew in comment #14 - mozilla still doesn't crash here on NT4... I'll install a newer build today and check again - and tomorrow evening I'll give it a try on my Notebook with Win 98 installed.
I've been hitting Build ID: 2002030403 hard for the past two days and I can't get Mozilla to crash at all. I'm surprised, because I was getting "ddhelp" error messages and others in earlier builds, indicating a system (Win 98) problem. Now it seems to be fine. Is anyone continuing to have problems?
Unless someone can point to a specific single reproducible crash with the same cause this bug isn't going anywhere. Feel free to resolve as Worksforme if it is no longer a problem.
-> wfm
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.