M14 chrases often, but gamespot is exstreme. I have yet to have it survive more than 2 minuttes. If you fail to chrash then try opening some links in new windows. Perhaps it is influenced by the fact that I tend to have min 2 windows open. Of other chrash pages bugzilla is a candidate.
We are not going to be able to sort this out unless you give us far more information. If you are using an SMP system, for example, this is understandable - Mozilla is currently not SMP safe AIUI. Please could you supply more detail about your problems and setup inside a week, or I will close this bug as INVALID. It might help to read the bug-writing guidelines at: http://www.mozilla.org/quality/bug-writing-guidelines.html or use the Bugzilla Helper at: http://www.mozilla.org/quality/help/bug-form.html to file a new bug. Gerv
No, I do not have a multiprocessor system.
Sorry - I figured that with 2 minuttes max survival time for me you could just point your browser and see for yourself. But using mozilla a little more it seems to be a more specifix problem, and requireing special behavior. (which I alway use, and therefore I get tons of crashes :( ) To reproduce you have to do this: 1) go to gamespot and right click a link to open a new window. (I used one of the links of the main stories, but any link seems to work) 2) left click another link. 3) the browser should just disappear (die) very shortly (the old window just have time to go blank) It doesn't matter if the page in the first window has rendered completely. clicking on a link in the first window still kills it. There is no debug messages written out to the shell. It does not seem seem to be limited to gamespot; fx www.freeciv.org displays the behaviour too. You might want to use that website as it has simpler HTML code, I should think. Sorry if my original post was a little short, but I had just enjured 4 mozilla chrases trying to post it, so my patience was worn :) May I suggest that this one gets a higher priority?
*** Bug 30827 has been marked as a duplicate of this bug. ***
Unable to reproduce on NT but with a couple of seperately reported bugs on this issue, marking Confirmed. Updating summary description to be more specific. cbegle, can you try to reporoduce and get a stack trace. Adding "crash" keywork and upping severity.
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Very frequent chrashes → [PP] Crash open link in new window then open another link in original window
oops, just ralized they were not independent reports, they were the same reporter.
*** Bug 30999 has been marked as a duplicate of this bug. ***
looks like this is XP. Seeing it on linux and windows.
OS: Linux → All
Hmm - funny. I tried downloading the freeciv main page to my computer and opening the links from there (I used links that was absolute (http...), so it should not matter if the main page is on my computer or on the web; it's cached by the browser.) I couldn't get it to chrash. Maybe it has to do with lag for the page you open the links from? The fact that any links on either www.freeciv.org and www.gamespot.com seems to reproduce the crash points to the main page. ps: www.slashdot.org, www.firingsquad.com and www.tomshardware.com does it too. Considering I only tested 4 pages to find those 3 it is an impressive statistic. Maybe I should try listing pages that do NOT crash :). *Thue tries another page and it chrases too* that 4 out of 5...
I'm the reporter of Bug 30827 (marked as a duplicate of this one). I've submitted three Talkback reports which should give you all the stack traces you need. Let me know if there is anything else you'd like me to do in Win98.
other similar bugs: 27723 29917 29655 Could you take a look at those three and see if anything strikes you as similar. cbegle, can we get any info from the talkbacks. How is that done?
Is that me you are asking? Anyway here goes: 27723: sounds like it has similarities, but obviously not completely the same procedure. And I could not reproduce it. 29917: I don't think this is related. I tried varying if the starting page and the page I opened had a "/" at the end (Actually before I saw this report), but it wasn't consistent; some pages without it still crashed. 29655: No. That one seems to be something building up; this one just dies at once. ps: the whole handling with many windows seems to be very error-prone in M14, where M13 was stable. Have you noticed that sometimes the cpu usage will go up to 100% and stay there, even when all open windows have finished loading their pages?
And then I would like to repport a bug about M14 inserting newlines where I didn't tell it too... :)
Funny little detail (noticed on www.nytimes.com): Leftclick on a link, then click stop before the old page goes away. Then open a link in a new window and leftclick on a link in the old window.(as you would normally do to reproduce the crash, always work on nytimes). The crash will NOT happen. Yet another indication that the cause is something about the site you click on links from, not the links you click on. I would conclude that the setting causing the crash is removed in the time from you leftclick a link to the old page goes away.
all of neil's crashes have the same stack trace. reassigning to layout. nsFrameImageLoader::Notify [d:\builds\seamonkey\mozilla\layout\base\src\nsFrameImageLoader.cpp, line 440] ns_observer_proc [d:\builds\seamonkey\mozilla\gfx\src\nsImageRequest.cpp, line 135] XP_NotifyObservers [d:\builds\seamonkey\mozilla\modules\libutil\src\obs.c, line 260] il_pixmap_update_notify [d:\builds\seamonkey\mozilla\modules\libimg\src\if.cpp, line 299] il_flush_image_data [d:\builds\seamonkey\mozilla\modules\libimg\src\scale.cpp, line 221] ImgDCallbk::ImgDCBFlushImage [d:\builds\seamonkey\mozilla\modules\libimg\src\if.cpp, line 164] il_gif_write [d:\builds\seamonkey\mozilla\modules\libimg\gifcom\gif.cpp, line 1501] GIFDecoder::ImgDWrite [d:\builds\seamonkey\mozilla\modules\libimg\gifcom\nsGIFDecoder.cpp, line 77] IL_StreamWrite [d:\builds\seamonkey\mozilla\modules\libimg\src\if.cpp, line 1005] 0x98f413c0 0x50534f43
Assignee: cbegle → troy
Component: Browser-General → Layout
QA Contact: asadotzler → petersen
Changing component to image lib. Looks more likely to be image lib related. Pam, I wonder if your change to use the threadsafe addref/release and my image related changes to gfx to do the same have made a difference?
Assignee: troy → pnunn
Component: Layout → ImageLib
QA Contact: petersen → elig
I get the following stack trace on the crash. ReconnectHack(void * 0x02dc1ca0, nsIStreamListener * 0x02da0510) line 160 + 9 bytes ImageNetContextImpl::GetURL(ilIURL * 0x02da0720, NET_ReloadMethod IMG_NTWK_SERVER, ilINetReader * 0x02da0450) line 679 + 35 bytes il_image_complete(il_container_struct * 0x039727d0) line 1564 ImgDCallbk::ImgDCBHaveImageAll(ImgDCallbk * const 0x03972ad0) line 191 + 12 bytes process_buffered_gif_input_data(gif_struct * 0x045bc7c0) line 694 gif_delay_time_callback(void * 0x039727d0) line 725 + 9 bytes timer_callback(nsITimer * 0x02da35b0, void * 0x02da0b10) line 70 + 12 bytes nsTimer::Fire() line 194 + 17 bytes nsTimerManager::FireNextReadyTimer(nsTimerManager * const 0x0145dde0, unsigned int 0) line 117 FireTimeout(HWND__ * 0x00000000, unsigned int 275, unsigned int 3626, unsigned long 1542938157) line 89 USER32! 77e71288() nsAppShellService::Run(nsAppShellService * const 0x01006a20) line 392 main1(int 1, char * * 0x00c64ce0, nsISplashScreen * 0x00000000) line 761 + 32 bytes main(int 1, char * * 0x00c64ce0) line 881 + 17 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77f1b9ea()
I'll have to dig into this. It could be the old bug where one animated image is in 2 frames (at the same dimensions). It crashes when one frame is unloaded and the other isn't. (grep 'reconnect hack', gfx/src). Neeti's stack trace points to this as the problem.
Status: NEW → ASSIGNED
Target Milestone: --- → M14
I think there are at least 2 different bugs described here. I'm not able to duplicate the one that occurs on gamespot, tomshardware, slashdot, etc. where you right click to open a link in a new window and then click around the 1st and 2nd window. I using a debug build from a tree I pulled last night.(03-20-00, NT). Could the reporter of the bug (and others who were able to reproduce the bug) try with the current build (03-21-00) see if they can still see the bug? The call stack reported by Neeti is a reproducable bug, and in fact can be reproduced by demo#9. I'm opening a new bug to cover this problem.(#32697) ----- Back to the original bug..... It could have been affected (or even fixed) by several recent check ins. Or I may not be able to reproduce it locally if it is related to timing. (I am currently pulling another new tree in background.) So....what do you see with the current tree? -P
I can't reproduce the crash with the latest build, so I guess it is fixed. I will mark this bug as fixed then (I guess I have the authority!?) You suggested that it may have been animated GIFS that caused the creashes. I think that is actually it. (I haven't really tested, just a generel impression. Anyway, it is fixed now) ps: The daily build is FAST compared to M14. And I only found ~5 bugs in my 2 minuttes of testing (nothing compared to M14). Impressive.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Thanks for responding so quickly. Onward to the next bug! -P
After 15 minutes, I can't reproduce a crash with this stack crawl on any recent build. (I can crash in MRJContext, but I've seen that before on other pages.) So, verifying as FIXED. email@example.com, if you ever see this again, could you please re-open this bug report with your comments? Thanks!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.