* Overview Description: Crash clicking Back buton from http://www.prs.net/midi.html * Steps to Reproduce: 1) Go to http://www.prs.net/midi.html 2) Wait until the page is completely loaded 3) Click the back button * Actual Results: The page disapear and then crash. Some times load part of the previous page but then crashes * Expected Results: Go back to the previous page. * Reproducibility: Build Date & Platform Bug Found: - Build ID: 2000021708 winNT build - Build ID: 2000021708 Win 2000 RC2 * Additional Builds and Platforms Tested On: - Build ID: 2000021708 Linux (works Ok, no crash) - M13 Win 2000 RC2 (works Ok, no crash) * Additional Information: Don't crash if the Mem cache is disabled. Don't crash loading the page locally(may be due relative links). Not sure about the component, sorry if I fail the correct one I'll work on a simplifiqued tescase if I have time... (the source code of the page is odd) Reported by "wares", I do the report for him because he had to go. * Possible related bugs: - #22092 very odd bug, like this. :-)

Hello. These steps caused my Linux 02/15/00 CVS to crash.

was able to reproduce this with a debug build from 2000-02-18. stack trace: nsFrameImageLoader::DamageRepairFrames(const nsRect * 0x0012fb80) line 541 + 15 bytes nsFrameImageLoader::Notify(nsIImageRequest * 0x040ba0c0, nsIImage * 0x040cb820, nsImageNotification nsImageNotification_kPixmapUpdate, int 0, int 0, void * 0x0012fbbc) line 420 ns_observer_proc(void * 0x040bbf50, long 4, void * 0x0012fc30, void * 0x040ba0c0) line 97 XP_NotifyObservers(OpaqueObserverList * 0x040bbfe0, long 4, void * 0x0012fc30) line 259 + 28 bytes il_pixmap_update_notify(il_container_struct * 0x040bbde0) line 307 + 18 bytes il_flush_image_data(il_container_struct * 0x040bbde0) line 218 + 9 bytes ImgDCallbk::ImgDCBFlushImage(ImgDCallbk * const 0x040bbbe0) line 162 + 12 bytes il_gif_write(il_container_struct * 0x040bbde0, const unsigned char * 0x0223a064, long 0) line 1499 process_buffered_gif_input_data(gif_struct * 0x04237320) line 669 + 16 bytes gif_delay_time_callback(void * 0x040bbde0) line 723 + 9 bytes timer_callback(nsITimer * 0x04238220, void * 0x0423f030) line 71 + 12 bytes nsTimer::Fire() line 194 + 17 bytes nsTimerManager::FireNextReadyTimer(nsTimerManager * const 0x019affe0, unsigned int 0) line 117 nsAppShell::Run(nsAppShell * const 0x0105ab90) line 116 nsAppShellService::Run(nsAppShellService * const 0x01028af0) line 401 main1(int 1, char * * 0x00c94540, nsISplashScreen * 0x00000000) line 651 + 32 bytes main(int 1, char * * 0x00c94540) line 770 + 17 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77f1ba3c()

updating component owner

layout thang.

I tried changing the image in the testcase to http://a1.g.a.yimg.com/7/1/31/000/us.yimg.com/a/vi/visa/sm.gif or http://www.mozilla.org/images/mozilla-banner.gif and no crash. :(

gandalf@megalis.com who reported the bug for me suggested I try an animated image instead. That crashed. I substituted the image in the html with: http://www.animfactory.com/images/aftitle21.gif and got a crash. So it appears that this is what is causing the crash: <TABLE> <CAPTION> <IMG SRC="animated.gif"> </CAPTION> </TABLE>

I think it's more likely an image lib problem

I think this bug is a duplicate of #28781. The problem occurs with the animated ad banners. Not marking as a duplicate yet. -P

Though this has the same call stack as 28781, its alittle different. In #28781, a crash will happen if you do a contextmenu back if there is an animated gif on the page. If you use a chrome back button, or Go menu back, you will not crash. In this bug, the chrome button will cause a crash. Something about the combination of the table and the image prevents a image group destroy from happening when we move off of the page. I'm hoping the extra info I get from this test case will help drill down on the problem in both bugs. -p

For the record, this doesn't crash: <table><tr><td> <img src=animatedimage.gif> </td></tr> </table>

Update: Current theory is that with some conditions (perhaps error conditions), the presentation context is leaked. If it is not released, we don't release the image group. If we don't release the image group, if we have an animating image, this animator doggedly continues to animate past its life time. So. look for nsPresContext leak. Check with Pink on status of #28781. -pn

See also bug 29397 and bug 28602. All three of these are probably duplicates of each other but I'll leave it to pnunn and/or neeti to mark them as such.

Nominating for beta1 since this is a crash and is occuring in many different situations (see my previous comment).

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

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

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

[Note to self: be sure to check dupes when verifying.]

Marking PDT+.

Bug 29397 has been marked as a dup of this bug. And, with the fix that Mike Pinkerton just made for bug 28781, the symptoms I reported in 29397 are now gone. So I'm closing this out by marking it a dup of 28781. *** This bug has been marked as a duplicate of 28781 ***

This is still broken on winNT build 2000022908 (M15 nightly) did the fix get into the M15 tree? bug 29397 and bug 28781 both workforme with this same M15 nightly. Both bugs seemed to be animated image causes crash. This bug is "animated image in a table caption" causes crash. Note: the image alone does not cause a crash.

Note: this is a _similiar_ bug not the same bug. The problem is something at a high level (shell) is not freed, which means the image group never gets the word to free itself, so the image continues to animate even though it doesn't have a view to display in. ----and that is the house that jack built. I'm trying to find who is leaking.

Well based on what jelwell and pnunn are saying, it was wrong to mark 29397 a dup of this bug. It is instead of dup of 28781 as demonstrated by the fact that Pinkerton's fix to the latter fixed the former. So I'm going to correct this -- otherwise it would appear as though 29397 is still not fixed (because this bug is not fixed) whereas indeed it is.

ChrisK: I need some table/view help. This crash shows a stack trace in the imglib, but I believe the problem is due to something >somewhere< not being freed, which means the cascade of frees down to the image group is also missing. If an animation happens to be in this group, it will be brought back to life with the timer callback. This bug only happens if an animated image is in the <caption> tag in a table. I have 2 versions of a testfile. One uses a static image and the other an animated image. The static page doesn't crash and the other page does when you move off of the page. I believe both pages don't clean up either a view or frame, but the animation forces access to the missing view or frame. In looking at the table and frame code, I'm having trouble seeing where nsTableCaptionFrame is freed. I may be chasing the wrong rabbit, but I think the basic idea is sound. Pink fixed a similiar crash in bug#28781 by adding a dont_AddRef to a document->GetShellAt(0). I've been looking at this all day, so my verbal skills maybe nil. Feel free to email or call tomorrow if this description doesn't make sense. my test files are at: jazz/users/pnunn/publish/aamap2.html : static image jazz/users/pnunn/publish/aamap.html : animated image I'll be happy to work with you on solving this. P.

I have a fix and have updated the status whiteboard.

Fixed.

Verified using the 3.2.00 builds on Mac OS 8.6, Win NT 4.0SP5, and RH Linux 6.0/GNOME. Specifically checked the steps to reproduce in this bug (thanks for the great bug, gandalf!), also confirmed steps in bug #29397. (The other bugs marked as duplicates were irreproducible.)