124556 - Crashing on random pages in 8-bit StaticGray class X11 server [nsImageGTK::DrawCompositedGeneral]

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Kelly Price]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221
BuildID:    2001122108

Mozilla will crash on pageload on random pages, including bugzilla.mozilla.org,
if it's running in an 8-bit StaticGray X11 server. (My monitor did a partial
death and I'm forced to run it at that color to do any serious work for two
weeks until a replacement is availible).

I'm using 'startx -- -depth 8 -cc StaticGray' on an XFree86 4.1 server (3dfx
Voodoo 3 PCI card).

Talkback ID's: TB2702028Y, TB2702010W, TB2702000X, TB2614591H.

Reproducible: Always
Steps to Reproduce:
1. Load up X11 in configuration above
2. Load up Mozilla, and go to bugzilla.mozilla.org or livejournal.com
3. *BANG!*

Actual Results:  Mozilla Crashes.

Expected Results:  Mozilla should load the page.

Comment 1

[R.K.Aa.]

Stephen: Can you please pull TB2702028Y

Comment 2

[[e-mail] (gone - use [e-mail] instead)]

nsImageGTK::DrawCompositedGeneral()
nsImageGTK::DrawComposited()
nsImageGTK::Draw()
nsRenderingContextImpl::DrawImage()
nsRenderingContextGTK::DrawImage()
nsImageBoxFrame::PaintImage()
nsImageBoxFrame::Paint()
PresShell::Paint()
nsView::Paint()
nsViewManager::RenderDisplayListElement()
nsViewManager::RenderViews()
nsViewManager::Refresh()
nsViewManager::DispatchEvent()
HandleEvent()
nsWidget::DispatchEvent()
nsWidget::DispatchWindowEvent()
nsWindow::DoPaint()
nsWindow::Update()
nsWindow::Update()
nsWindow::UpdateIdle()
libglib-1.2.so.0 + 0x1132a (0x4036932a)
libglib-1.2.so.0 + 0x10308 (0x40368308)
libglib-1.2.so.0 + 0x10913 (0x40368913)
libglib-1.2.so.0 + 0x10aac (0x40368aac)
libgtk-1.2.so.0 + 0x8d7e7 (0x4028b7e7)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main()
libc.so.6 + 0x1d2eb (0x404aa2eb) 

Comment 3

[R.K.Aa.]

forgot to change component

Comment 4

[Kai Lahmann (is there, where MNG is)]

reporter, can you still reproduce it with RC1 or another recent build? If not,
set the bug to "worksforme"

Comment 5

[Kelly Price]

Reproducable on build 2002042007, Talkback incident TB5418678Y

Comment 6

[Kai Lahmann (is there, where MNG is)]

confirmed as of comment #5

Comment 7

[Kyle Yuan]

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

Comment 8

[Kyle Yuan]

still reproducable on current trunk build.

Comment 9

[Nicolas Pioch]

comment at http://bugzilla.mozilla.org/show_bug.cgi?id=178152#c13

If we close bug 178152,
this bug should be enlarged to color 8-bit displays, all Unix platforms

now that RFE/ bug 14835 has been checked in,
the MTBF on Unix 8-bit displays has gone down to a few seconds before
Mozilla/1.2b crashes and makes it completely unusable as an application.

(I'm running it on Solaris 8, sparc Ultra-10, 256 color display)

Comment 10

[Kyle Yuan]

Attachment: make DrawCompositedGeneral works

the original nsImageGTK::DrawCompositedGeneral uses a wrong loop limit
(ximage->width*ximage->height) that may exceed the memory boundary.

This is a serious problem that make mozilla unusable on 8-bit(or lower)
display.

seeking r=/sr=.

Comment 11

[Andrew McGuinness]

I just tested the patch from Kyle Yuan, and it fixes the problem for me.
(I originally reported bug 178152)

Comment 12

[Kyle Yuan]

taking...

Comment 13

[tor]

Comment on attachment 106427 [details] [diff] [review]
make DrawCompositedGeneral works

sr=tor

Comment 14

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 106427 [details] [diff] [review]
make DrawCompositedGeneral works

approved for 1.2; please get it in ASAP

Comment 15

[Kyle Yuan]

checked in trunk and 1.2 branch!

Comment 16

[Nicolas Pioch]

Unfortunately I've pulled Mozilla/1.2 RELEASE from cvs yesterday
and this patch hasn't made it into the release :-/

Patching manually and rebuilding my 1.2 solaris8 copy...

Any idea what went wrong?

Comment 17

[Nicolas Pioch]

I've double checked that I did not screwup when checking out the
MOZILLA_1_2_RELEASE from CVS yesterday...

Downloading
ftp://ftp.mozilla.org/pub/mozilla/releases/mozilla1.2/src/mozilla-source-1.2.tar.bz2

file included mozilla/gfx/src/gtk/nsImageGTK.cpp is dated 17 Oct !

-rw-r--r--   1 pioch    user       62155 Oct 17 21:20 nsImageGTK.cpp

and doesn't have the patch attached on this bug...

Comment 18

[Kyle Yuan]

Hi, Nicolas, I don't know what tag was used for building 1.2, but I used 
MOZILLA_1_2_BRANCH to check in my code. You can check it at the bonsai page: 
http://bonsai.mozilla.org/cvsquery.cgi?
treeid=default&module=all&branch=MOZILLA_1_2_BRANCH&sortby=Date&hours=2&date=exp
licit&mindate=08%2F05%2F2002+00%3A00&maxdate=&cvsroot=%2Fcvsroot

By checking the log of nsImageGTK.cpp, I also wonder why the 
MOZILLA_1_2_RELEASE tag is 1.116 but my checked in version is 1.118? I'm pretty 
sure you can get the latest 1.2 source by using MOZILLA_1_2_BRANCH tag.

CCing leaf to clarify the 1.2 source tarball issue.

Comment 19

[Malcolm Rowe]

Confirming - pulling by tag MOZILLA_1_2_BRANCH gets version 1.116.2.1, which 
has the fix, pulling by tag MOZILLA_1_2_RELEASE gets version 1.116, which does 
not (huh?).

Version 1.118 was the result of the checkin to HEAD (the trunk).

I *think* tor created the 1.116.2 branch with the checkin for bug 174831, but 
the fix for that bug *is* included if you pull against 1.116 / 
MOZILLA_1_2_RELEASE.

cvs log for the file shows a version 1.116.0.2 against MOZILLA_1_2_BRANCH - I 
don't know what that's about.

Apologies if this confuses things even more - I'm not a cvs expert.

Comment 20

[Robert Kaiser]

Malcolm:
Due to cvs' internal handling of revision numbers, 1.116.0.2 == 1.116.2 (any .0
are only for better internal handling, and are not shown most times, but cvs log
is known to show those even if it shouldn't).

Comment 21

[Nicolas Pioch]

Restarting all over...

ftp://ftp.mozilla.org/pub/mozilla/releases/mozilla1.2/src/mozilla-source-1.2.tar.bz2

+ applying manually on mozilla/gfx/src/gtk/nsImageGTK.cpp patch
http://bugzilla.mozilla.org/attachment.cgi?id=106427&action=view

and building produces a sparc Mozilla 1.2 that works and doesn't exhibit
bug 178152 (critical, crasher)

In case anyone is interested I've made my sparc-sun-solaris2.8 "fixed" build
available at ftp://depot.mcom.com/pub/pioch/mozilla-1.2/

The README is 14 KB long (!!!) and details everything.

PS: Could some Linux user confirm the un-usability of the Linux Mozilla/1.2
"official distributions" and verify they core dump on 8bit displays
when you select an image ?

Comment 22

[Malcolm Rowe]

It's more than just this checkin that's affected, I'm afraid.

Rather than continue to spam this bug, I've opened bug 182506.

Robert: thanks for the explanation.

Comment 23

[Olivier Cahagne]

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