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 (a.mcguinness@ntlworld.com) from 1.2beta mozilla 1.1 doesn't crash ; it doesn't try to make the image blue (bug 14835)

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 ?

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.

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

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.

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)

Reproduced with latest nightly. TB13455905K

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.

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.

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

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

Dup of 124556. If I was wrong, please feel free to reopen this bug. *** This bug has been marked as a duplicate of 124556 ***

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.

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

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

All working fine on 20021122 build

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! :-)