178152 - crash if I select an image [@ nsImageGTK::DrawCompositedGeneral ]

Status: RESOLVED DUPLICATE of bug 124556

(Core :: DOM: Selection, defect)

Description

[Andrew McGuinness]

User-Agent:       Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2b) Gecko/20021016
Build Identifier: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2b) Gecko/20021016

Selecting an image like the mozilla logo causes a crash.  I assume this is
related to the fix for bug 14835



Reproducible: Always

Steps to Reproduce:
1.Go to a page with an image
2.drag with the mouse from some bit of text over the image


Actual Results:  
crash.  Occasionally it freezes instead.

Expected Results:  
turned the image bluish.

This happens on only one of my machines; a pentium 133 running debian woody.  It
works fine on my PII laptop and Celeron desktop.

I first found this in phoenix 0.3, and have duplicated it in various builds
including mozilla 1.2beta binary download and CVS from yesterday (20021102)
compiled myself.  There should be an automatic feedback result from it with my
email on ([e-mail]) from 1.2beta

mozilla 1.1 doesn't crash ; it doesn't try to make the image blue (bug 14835)

Comment 1

[Olivier Cahagne]

can you post Talkback ID for this crash 'mozilla/bin/components/talkback/talkback' ?
Do you crash with a fresh profile ? Do you still crash with a nightly build ?

Comment 2

[Andrew McGuinness]

talkback TB13444203X
I haven't tried a nightly build, but I built overnight last night from CVS and
got the same crash there.
(Give me a few hours to download a binary build)
Still get the crash with a fresh profile.

Last time I got 'Warning: Cannot allocate colormap entry for "#c0c0c0"' on the
xterm I ran it from.  That made me think the key factor is that I am running X
in 8-bit colour depth.

I changed my X settings from 8bit x 800 x 600 to 16bit x 640 x 480 and the
problem went away.

Comment 3

[Andrew McGuinness]

I can now reproduce the crash on another machine by setting 8-bit colour depth
in the X server.

Comment 4

[Nicolas Pioch]

I have had the exact same problem (constant crashes of Moz/1.2b)
on sparc-sun-solaris2.8 (Ultra10) running with a display in 8 bit mode.

Until I read this I hadn't realized it was related to the selection including
an image, but now I can trivially reproduce it.

Comment 5

[Nicolas Pioch]

About to start rebuilding Mozilla/1.2b for Solaris8 in debug mode to be able
to get a stack trace (hopefully in about 4 hours)

Comment 6

[Andrew McGuinness]

Reproduced with latest nightly.   TB13455905K

Comment 7

[Olivier Cahagne]

Attachment: Stack trace Linux build 20021030

Comment 8

[Olivier Cahagne]

maybe not a regression after all: bug 124556, although this is now more serious
as this new blue image selection triggers the crash more easily.

Comment 9

[Olivier Cahagne]

fwiw, it doesn't affect Win32 builds as I couldn't get Mozilla to crash in 8-bit
mode (256 colors) using 20021103 on Win2k.
The function nsImageWin::DrawComposited looks quite different in nsImageWin.cpp
anyway.

Comment 10

[Nicolas Pioch]

Attachment: pstack (solaris8) after crash when displaying about: page and selecting mozilla logo

gdb hangs, so I have to use pstack on the stopped/crashed process:

GFX: dpi=90 t2p=0.0625 p2t=16 depth=8
...
Document about: loaded successfully

Program received signal SIGSEGV, Segmentation fault.
0xfe7c20c4 in t_splay () from /usr/lib/libc.so.1
(gdb) bt
#0  0xfe7c20c4 in t_splay () from /usr/lib/libc.so.1
#1  0xfe7c1f14 in t_delete () from /usr/lib/libc.so.1
#2  0xfe7c15bc in _malloc_unlocked () from /usr/lib/libc.so.1
#3  0xfe7c1414 in malloc () from /usr/lib/libc.so.1
#4  0xfeabf8c0 in XGetImage () from /usr/lib/libX11.so.4
(hangs forever)

The interesting stuff in the pstack is the function that calls XGetImage:

 fc30c410 _ZN10nsImageGTK17DrawCompositeTileER19nsIRenderingContextPviiiiiiii
(9
0f390, 555270, 83cda0, 0, 0, 20) + 258
 fc2c5b70 _ZN10nsImageGTK8DrawTileER19nsIRenderingContextPviiRK6nsRect (90f390,

555270, 83cda0, 0, 0, ffbec610) + 32c
 fc2ff554 _ZN22nsRenderingContextImpl8DrawTileEP13imgIContaineriiPK6nsRect
(5552
70, 71a8c0, 0, 0, ffbec6a0, fc2ff2f0) + 264

Comment 11

[Nicolas Pioch]

Attachment: demangled pstack, solaris8

Same as above, but C++ demangled pstack output

 --- called from signal handler with signal 11 (SIGSEGV) ---
 fe7c20c4 t_splay  (984cc8, 76158, fe838018, 0, 9, 0) + 34
 fe7c1f0c t_delete (984cc8, fe838018, fe83e824, fe83e8a4, fe83e8a0, 0) + 50
 fe7c15b4 _malloc_unlocked (1a90, 984cc8, fe838018, 1a90, 984cc8, 0) + 18c
 fe7c140c malloc   (1a90, 1baa, 0, 0, 1baa, 0) + 20
 feabf8b8 XGetImage (f69a0, 2, ffffffff, 1a90, c8, 22) + dc

 fc30c410 nsImageGTK::DrawCompositeTile(nsIRenderingContext&, void*, int, int,
int, int, int, int, int, int) (90f390, 555270, 83cda0, 0, 0, 20) + 258

 fc2c5b70 nsImageGTK::DrawTile(nsIRenderingContext&, void*, int, int, nsRect
const&) (90f390, 555270, 83cda0, 0, 0, ffbec610) + 32c

 fc2ff554 nsRenderingContextImpl::DrawTile(imgIContainer*, int, int, nsRect
const*) (555270, 71a8c0, 0, 0, ffbec6a0, fc2ff2f0) + 264

 fb1cf190 nsFrame::Paint(nsIPresContext*, nsIRenderingContext&, nsRect const&,
nsFramePaintLayer, unsigned) (9c058c, 916f80, 555270, ffbec920, 2, 2) + 77c

 fb200d14 nsImageFrame::Paint(nsIPresContext*, nsIRenderingContext&, nsRect
const&, nsFramePaintLayer, unsigned) (9c058c, 916f80, 555270, ffbec920, 2, 0) +
c54

 fb1c7cb4 nsContainerFrame::PaintChild(nsIPresContext*, nsIRenderingContext&,
nsRect const&, nsIFrame*, nsFramePaintLayer, unsigned) (9bfb80, 916f80, 555270,
ffbecb20, 9c058c, 2) + 274

Comment 12

[Kyle Yuan]

Dup of 124556. If I was wrong, please feel free to reopen this bug.

*** This bug has been marked as a duplicate of 124556 ***

Comment 13

[Nicolas Pioch]

Maybe the root cause of both bugs is the same, however:

Until RFE/ bug 14835 has been checked in last month, there was no problem
on color 8-bit displays (256 colors)

Suddenly, when 14835 was checked in (in Mozilla/1.2b), highlighting text
that includes an image is supposed to highlight (blue-ish) the image
-> immediate core dump

This makes the MTBF on Unix go down from hours to a few seconds per session.

Since bug 124556 has been open for month with zero visible progress,
my suggestion is that bug 14835 should be backed out for Mozilla/1.2 release
so that we get the MTBF back into a few hours and not ship a release
that core dumps every few seconds on Unix platforms.

Comment 14

[Olivier Cahagne]

I agree with Nicolas, we should leave both open and make one depend on the other.

Comment 15

[Kyle Yuan]

I've already got a fix for bug 124556. If the problem is still here after that
fix checked in, please reopen this bug.

Comment 16

[Andrew McGuinness]

All working fine on 20021122 build

Comment 17

[Nicolas Pioch]

confirming that Kyle's patch for bug 124556,
manually re-injected in the Mozilla/1.2 release,
fixes this issue on sparc-sun-solaris2.8 (sparcv9)

Well done Kyle! :-)