Closed Bug 124556 Opened 23 years ago Closed 22 years ago

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

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: bugs, Assigned: yuanyi21)

References

Details

(Keywords: crash)

Attachments

(1 file)

make DrawCompositedGeneral works
1.41 KB, patch
pavlov
: review+
tor
: superreview+
jesup
: approval+
Details | Diff | Splinter Review 
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.
Stephen: Can you please pull TB2702028Y
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)
Keywords: crash
Summary: Crashing on random pages in 8-bit StaticGray class X11 server → Crashing on random pages in 8-bit StaticGray class X11 server [nsImageGTK::DrawCompositedGeneral]
forgot to change component
Assignee: asa → pavlov
Component: Browser-General → ImageLib
QA Contact: doronr → tpreston
reporter, can you still reproduce it with RC1 or another recent build? If not,
set the bug to "worksforme"
Reproducable on build 2002042007, Talkback incident TB5418678Y
confirmed as of comment #5
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 178152 has been marked as a duplicate of this bug. ***
still reproducable on current trunk build.
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)

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=.
I just tested the patch from Kyle Yuan, and it fixes the problem for me.
(I originally reported bug 178152)

taking...
Assignee: pavlov → kyle.yuan
Attachment #106427 - Flags: superreview?(tor)
Attachment #106427 - Flags: review?(pavlov)
Comment on attachment 106427 [details] [diff] [review]
make DrawCompositedGeneral works

sr=tor
Attachment #106427 - Flags: superreview?(tor) → superreview+
Attachment #106427 - Flags: review?(pavlov) → review+
Comment on attachment 106427 [details] [diff] [review]
make DrawCompositedGeneral works

approved for 1.2; please get it in ASAP
Attachment #106427 - Flags: approval+
checked in trunk and 1.2 branch!
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
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?
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...


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.
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.
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).
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 ?


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.
*** Bug 183271 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: