Reloading page crashes Mozilla

VERIFIED WORKSFORME

Status

()

--
critical
VERIFIED WORKSFORME
18 years ago
5 years ago

People

(Reporter: wolruf, Assigned: pavlov)

Tracking

({crash, testcase})

Trunk
crash, testcase
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
Mozilla build: 20010729 on Linux and 20010729 Win2k.

Load URL: http://www.tweak3d.net/reviews/intel/tualatin then re-load the page or
move from page to page (with this review) until page 5, 6 or 7 (this would be
http://www.tweak3d.net/reviews/intel/tualatin/7.shtml), and it should crash.
This has been observed by 4 different people on #mozilla and #mozillazine.

Behaviour: Mozilla crashes with Talkback data: TB33499508G (Linux), TB33499831X
(Win2k).
Expected behaviour: not crashing, IE 5.5 and Netscape 4.76 (Linux) do not crash.

Comment 1

18 years ago
Confirming 2001072711 trunk for MacOS 9.1

Calling chain using A6/R1 links
  Back chain  ISA  Caller
  00000000    PPC  3F164818  
  0B23D050    PPC  3F14FB2C  main+00130
  0B23CFF0    PPC  3F14EDA8  main1(int, char**, nsISupports*)+00C1C
  0B23CCC0    PPC  3ECB4220  nsAppShellService::Run()+00018
  0B23CC80    PPC  3E680AAC  nsAppShell::Run()+00048
  0B23CC30    PPC  3E6814FC  nsMacMessagePump::DoMessagePump()+0003C
  0B23CBE0    PPC  3E681BD8  nsMacMessagePump::DispatchEvent(int,
EventRecord*)+0014C
  0B23CB90    PPC  3E696BF4  Repeater::DoIdlers(const EventRecord&)+00030
  0B23CB50    PPC  3E697048  nsTimerPeriodical::IdleAction(const EventRecord&)+00014
  0B23CB10    PPC  3E697404  nsTimerPeriodical::FireNextReadyTimer()+0003C
  0B23CAD0    PPC  3E69720C 
nsTimerPeriodical::FireAndReprimeTimer(nsTimerImpl*)+00094
  0B23CA80    PPC  3E697F40  nsTimerImpl::Fire()+00048
  0B23CA40    PPC  3E593520  imgContainer::Notify(nsITimer*)+00470
  0B23C920    PPC  3E58E8F8  imgRequest::FrameChanged(imgIContainer*,
nsISupports*, gfxIImage
Frame*, nsRect*)+00074
  0B23C8C0    PPC  3E591400  imgRequestProxy::FrameChanged(imgIContainer*,
nsISupports*, gfxI
ImageFrame*, nsRect*)+00028
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
Hardware: PC → All

Comment 2

18 years ago
-> cache.

Can you provide the cache settings you are using in each case?
Component: Networking → Networking: Cache
QA Contact: benc → tever

Comment 3

18 years ago
The win2k talkback was mine.

Cache settings: Memory Cache: 4096
                Disk Cache  : 50000
Compare: Automatic

Comment 4

18 years ago
-> gordon

Comment 5

18 years ago
From the stack crawl, this looks more like we should start with imgLib.

->pav
Assignee: neeti → pavlov
Component: Networking: Cache → ImageLib
QA Contact: tever → tpreston
(Reporter)

Comment 6

17 years ago
Using build ID 20010822 on Win2k, it still crashes and quicker than usual (on
page "3").
I use the default  Mozilla's settings as this is a fresh install where Mozilla
had never been installed.
Cache settings: Memory Cache: 4096  Disk Cache  : 50000
Compare: Automatic
(Reporter)

Comment 7

17 years ago
Found another URL on the same site that crashes Mozilla more easily:
http://www.tweak3d.net/reviews/radeonve/4.shtml
It crashes Mozilla 2001083103 on Win2k when reloading it several times or
shift-reloading it.
Another thing is that when disabling Cache (Cache -> Never), it still crashes.
Various Talkback IDs: TB34792321G (cache disabled), TB34792217G (cache automatic).
I tried reloading every image from this URL several times but it won't crash
(through Page Info -> images and scrolling back and forth).
(Reporter)

Comment 8

17 years ago
Created attachment 47923 [details]
Reduces test case (save on local filesystem then hit reload many many times until it crashes)

Comment 9

17 years ago
Created attachment 47930 [details]
backtrace w current CVS build. Crashed each time after clicking link to "Archives" (upper right)

Comment 10

17 years ago
CORR: i meant link Archives upper LEFT
(Reporter)

Comment 11

17 years ago
Created attachment 47951 [details]
Even more reduced testcase (keep Ctrl-R pressed for 4-5 seconds, then release it it's not crashed already)
(Reporter)

Comment 12

17 years ago
The last attachment shows bad HTML but, unfortunately, when I try to clean it
(removing unclosed tags), crash is more difficult to trigger. While strpping the
page to isolate the bug, the HTML code became more and more ugly but it kept
crashing with the same trace.
I believe there's a mix with the <center, <td, <iframe tags, perhaps corrupt
images or JS parsing too (even though it also crashes when JavaScript is disabled).
TO trigger the bug, please save the last attachement 47951 on your local hard
disk and reload it with Ctrl-R (faster than clicking on the mouse) during some
seconds then release, it'll generally crash (using build 2001083103 on Win2k). 
(Reporter)

Updated

17 years ago
Keywords: testcase
(Reporter)

Comment 13

17 years ago
wfm using build 2001100503 on Win2k. Neither URLs or testcases trigger the bug.
Marking WORKSFORME.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 14

17 years ago
Verified WFM Win XP build 2001120303, Linux build 2001120308, Mac OS 9 build
2001120307
Status: RESOLVED → VERIFIED

Comment 15

10 years ago
Crashtest added as part of http://hg.mozilla.org/mozilla-central/rev/54417ebbaea2
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.