30600 - [PP] Crash open link in new window then open another link in original window

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect, P3)

Description

[thue]

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.

Comment 1

[Gervase Markham [:gerv]]

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

Comment 2

[thue]

No, I do not have a multiprocessor system.

Comment 3

[thue]

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?

Comment 4

[Asa Dotzler [:asa]]

*** Bug 30827 has been marked as a duplicate of this bug. ***

Comment 5

[Asa Dotzler [:asa]]

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.	

Comment 6

[Asa Dotzler [:asa]]

oops, just ralized they were not independent reports, they were the same reporter.

Comment 7

[Asa Dotzler [:asa]]

*** Bug 30999 has been marked as a duplicate of this bug. ***

Comment 8

[Asa Dotzler [:asa]]

looks like this is XP. Seeing it on linux and windows.

Comment 9

[thue]

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...

Comment 10

[Neil Fraser]

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.

Comment 11

[Asa Dotzler [:asa]]

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?

Comment 12

[thue]

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?

Comment 13

[thue]

And then I would like to repport a bug about M14 inserting newlines where I
didn't tell it too... :)

Comment 14

[thue]

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.

Comment 15

[Christine Begle]

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

Comment 16

[troy]

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?

Comment 17

[neeti]

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()

Comment 18

[pnunn]

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.

Comment 19

[pnunn]

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

Comment 20

[thue]

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.

Comment 21

[pnunn]

Thanks for responding so quickly.

Onward to the next bug!
-P

Comment 22

[Eli Goldberg]

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. [e-mail], if you ever see this again,
could you please re-open this bug report with your comments?

Thanks!