47816 - scrolling on PNG/alpha page causes crash

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect, P3)

Description

[Greg Roelofs]

Linux/x86/glibc with talkbalk nightly 2000-08-05-04-M17.  I'm not sure if
talkbalk was able to send from this machine; there's no record of an outgoing
message in my logs, so I assume not.

I can crash Mozilla reproducibly (three times in a row now) by allowing the URL
above to fully load (or scrolling down to the bottom four images and watching
them load), and then scrolling.  It usually happens when scrolling up.  This
appears at first glance to be a duplicate of an older bug I filed, but this one
seems specific to transparency or larger images or something--scrolling on the
PNG home page, which previously caused a crash, does not crash with this build.

Oops, I take that back--it just crashed, too, but it required around five full
top-to-bottom-to-top scrolls, not the single down-and-up of the older bug.

Comment 1

[Greg Roelofs]

adding "crash"

Comment 2

[Jeffrey Baker]

For reference, the previous similar bug is Bug 40942.  Greg, are you sure this
one is different?

At any rate, I couldn't reproduce this on the latest Linux M17 build,
2000080605, nor on the latest Linux M18 build.  Sadly Bug 40942 still crashes
me, so I am reopening it.

Comment 3

[tor]

Need a stack trace to get anywhere on a bug that we can't reproduce.

Try the patch from bug 47679.

Comment 4

[Greg Roelofs]

Jeffrey, thanks for the previous bug number; I'm not 100% certain, but this one
is probably the same thing.  The uncertainty is because previously I never blew
away Mozilla on the pngs-img page, while now I do so without fail.

I downloaded 2000-08-06-05-M17 this morning and tested just now; it fails in
exactly the same way.  Testing on the PNG sitemap crashed the browser in about 2
and a half up/down cycles.  I couldn't find any recent M18 builds for Linux when
I downloaded, so I don't have that to test.  (This is a 28.8k modem, so we're
talking overnighters here...)

Tim, I no longer have time or disk space to compile the beast, and my efforts to
get gdb to do anything useful have failed.  Here's the little script I put
together when "./run-mozilla.sh -g mozilla-bin -d gdb" failed:

#!/bin/sh
MOZILLA_FIVE_HOME=.
  LD_LIBRARY_PATH=.:/usr/local/experimental/lib
     LIBRARY_PATH=.
       SHLIB_PATH=.
          LIBPATH=.
       ADDON_PATH=.
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
export MOZILLA_FIVE_HOME LD_LIBRARY_PATH LIBRARY_PATH SHLIB_PATH LIBPATH \
     	ADDON_PATH MOZ_PROGRAM MOZ_TOOLKIT moz_debug
exec /usr/bin/gdb ./mozilla-bin

Regardless, I get something like this every time:

GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(no debugging symbols found)...
(gdb) run
Starting program: /usr/local/www/mozilla-20000806/./mozilla-bin 
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
warning: shared library handler failed to enable breakpoint

Program received signal ?, Unknown signal.
0x4024f24a in ?? () from /lib/libc.so.6
(gdb) continue
[hangs indefinitely]

In a previous bug, I was told that my version of gdb (probably this one) was too
old to do some sorts of debugging.  If that's the case here, then it will have
to wait--I don't have time to find the newer gdb sources and compile them.

However, I regularly get talkback boxes and regularly click "send"; if someone
can tell me how to intercept what it's trying to send so that I can do so
manually, I'll be more than happy to provide that info.  But judging by bug
40942, others have not had much trouble reproducing this kind of crash, if not
on this exact page.

Comment 5

[tor]

Checked in what is hopefully the final word in the nsImageGTK::DrawComposited
clipping code.  Should fix this problem.

Comment 6

[Greg Roelofs]

As I was noting before my update collided with Tim's and died a horrible death:

Tim's 47679 patch, as embodied in 2000-08-07-20-M18, fixes all scrolling crashes
I was seeing.  I had therefore marked this as a dupe of 47679.

Comment 7

[shrirang khanzode]

verified...no crash (linux:build 2000081405m18).