Browser crashes on page load

VERIFIED DUPLICATE of bug 52275

Status

SeaMonkey
General
P3
critical
VERIFIED DUPLICATE of bug 52275
17 years ago
13 years ago

People

(Reporter: Darrell Brogdon, Assigned: Stuart Parmenter)

Tracking

({crash, testcase})

Trunk
x86
Linux
crash, testcase

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
The browser seems to be crashing about mid-way through the loading of "main.php"
(http://www.brogdon.net/~darrell/main.php).  If you load this page directly
(i.e. not within the frames) it doesn't crash the browser.  However, its when
you load the full page (http://www.brogdon.net/~darrell/) that it crashes the
browser.

I've only noticed this on the above site so far but if its happening with my
site I'm sure its happening somewhere else.

I have confirmation from other people that it is crashing their version of
Mozilla as well.  I'm using Build ID: 2000091808 and I've noticed this happening
for about a week now.

Comment 1

17 years ago
Wfm on 091905 Win32. Please confirm on Linux.

Comment 2

17 years ago
OK, this crahses me on linux but not on win32 or mac 091908 builds.  Need a
stack trace.

Comment 3

17 years ago
I see the crash on Linux 2000-09-18-08. I could create a reduced testcase.
To reproduce the crash:
1) save the first attachment, a reduced version of frm_main.php
2) save the second attachment, a reduced version of header.php
3) download http://www.brogdon.net/~darrell/images/hdr_delimiter.png
  and save it as hdr_delimiter.png. These 3 files must be in the
  same directory.
4) load frm_main.php into mozilla

I've tried with a gif instead of a png and did not crash. I've also tried to
put the image's full URL in header.php and it did not crash. Also if the
path in header.php is not valid (does not point to a file) it does not crash.

Imagelib?

Marking confirmed, adding crash and testcase keywords.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash, testcase

Comment 4

17 years ago
Created attachment 15068 [details]
reduced version of frm_main.php

Comment 5

17 years ago
Created attachment 15069 [details]
reduced version of header.php

Comment 6

17 years ago
could be parser or imagelib.

could you post the full testcase on a server perhaps? not everyone has php
running on linux.

Comment 7

17 years ago
I don't have php running. These files are just plain html so you should
be able to reproduce by just saving them on a local filesystem.

Comment 8

17 years ago
updating component and setting default owner.
Assignee: asa → pollmann
Component: Browser-General → HTMLFrames
QA Contact: doronr → petersen

Comment 9

17 years ago
Created attachment 15294 [details]
stack trace of crash

Comment 10

17 years ago
Verified that this does not crash on Win32 (but crashes every time on Linux). 
Also verified that if the image is replaced with a GIF it works fine on Linux 
and Win. I tried another PNG and did not get a crash (though the other PNG I 
tried did not display at all on Win or Linux - maybe this is an unrelated bug)

Based on the stack, and the fact that the crash is only on GTK, I'm guessing 
that this is not imagelib. Handing over to the local GTK guru...
Assignee: pollmann → pavlov
Component: HTMLFrames → Browser-General

Comment 11

17 years ago
I believe this is bug 52275, tor's bug for crash with certain images on Linux

(top of stack is 
#0  0x410b8dc3 in nsImageGTK::DrawComposited ()
#1  0x410a9f09 in nsImageGTK::Draw ()
#2  0x410afd9f in nsRenderingContextGTK::DrawImage ()  ...)

*** This bug has been marked as a duplicate of 52275 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 12

17 years ago
Same stack traces, plus now that 52275 has been fixed this page renders fine in
Linux build 2000110721: Verified dupe.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.