Crash when using text zoom on files with long lines

RESOLVED WORKSFORME

Status

defect
--
critical
RESOLVED WORKSFORME
17 years ago
11 years ago

People

(Reporter: mozilla-org, Assigned: blizzard)

Tracking

({crash, intl})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

17 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021020
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021020

I created a file with 1,000,000 occurences of the # character on the same line.
I load the file up in mozilla and it works fine.  When I change the text zoom to
354%, it also works fine.  When I change it to 355%, it crashes.

At 2000% zoom, I can have a file up to 464 without crashing.  A file with 465 #
chracters causes it to crash.

At 1000% zoom, I can have up to 922 without crashing.  Again, 923 causes it to
crash.


Reproducible: Always

Steps to Reproduce:
1.  Create a file with many (over 500) # characters on a single line.
2.  Open up the file.
3.  Use View/Text Zoom/Other and enter 2000.

Actual Results:  
/home/patearl/mozilla/run-mozilla.sh: line 444: 26298 Segmentation fault     
"$prog" ${1+"$@"}


Expected Results:  
Display the page instead of crashing.

Here are the libraries that ldd mozilla-bin reports.  I'm not sure if the shell
script changes which shared libraries are used, but these are the ones it finds
before any changes.

libc6                    2.2.5-14
libgtk1.2                1.2.10-ximian.25
libglib1.2               1.2.10-ximian.2
xlibs                    4.1.0-17
libstdc++2.9-glibc2.1    2.91.66-4

I am running Debian with the following:
Linux patmain 2.4.18 #1 Sun Jul 28 19:00:16 MDT 2002 i686 unknown

Updated

17 years ago
Keywords: crash, stackwanted

Comment 1

17 years ago
with linux trunk build 20021020 Mozilla grabs a lot of memory and then gets
killed by the kernel (I have 768 MB RAM).
Component: Browser-General → Internationalization

Comment 2

17 years ago
Can confirm this for Mozilla 1.2b build 2002101612, Linux Mandrake 9.0. Made a
file with 10000 'i's and opend it => worked. Changed zoom to custom: 300% and it
crashed (full CPU utilization and allocated huge amounts of memory until it got
killed).

Comment 3

17 years ago
Posted file stacktrace
broke in with gdb and caught it doing this.
_XReserve_Bytes calls itself forever until Mozilla dies.

Comment 4

17 years ago
==> Intl for real.
this looks like it might be an XFree86 bug, but if so, perhaps Mozilla can do
something to avoid it.
Assignee: asa → yokoyama
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: stackwanted
QA Contact: asa → ruixu

Updated

17 years ago
Keywords: intl
QA Contact: ruixu → ylong

Comment 5

17 years ago
crashing in nsXFontAAScaledBitmap::DrawText8or16
assign to shanjian
Assignee: yokoyama → shanjian

Comment 6

17 years ago
if it is happening in the aasb code I should look at this
Assignee: shanjian → bstell

Comment 7

17 years ago
win32 trunk build 2002111508 win98se, crashing in GKLAYOUT.DLL
Talkback IDs TB14075081G, TB14074908W

http://www.the-webwizard.co.uk/

Text zoom (up or down to any value) causes a crash.  With js disabled there is
no content, and subsequently no crash.  The content of the right panel is one
long line, but I didn't count the number of characters
(http://www.the-webwizard.co.uk/panel/news.js)

Is this the same bug?  If so, then it's not just Linux.

Comment 8

17 years ago
> Is this the same bug?

nope.  You are crashing in layout, and this specific bug is definitely
linux-only.  Please file a new bug.

Comment 9

15 years ago
*** Bug 266966 has been marked as a duplicate of this bug. ***

Comment 10

15 years ago
over to gtk
Assignee: bstell → blizzard
Component: Internationalization → GFX: Gtk
QA Contact: amyy → ian

Comment 11

13 years ago
I don't see this with a gtk2 build (SM 1.0 and trunk) or a cairo-gtk2 build.

resolving WFM
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.