Closed Bug 198946 Opened 21 years ago Closed 21 years ago

repainting horribly broken - Trunk [@ ComputeAlphasByByte]

Categories

(Core Graveyard :: GFX: Gtk, defect)

Product:
Core Graveyard
Component:
GFX: Gtk
Version:
Other Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: kairo, Assigned: roc)

References

Details

(4 keywords)

Crash Data

Attachments

(2 files)

backtrace, non-debug
4.58 KB, text/plain
Details
roc's fix, in patch form.
899 bytes, patch
Details | Diff | Splinter Review 
On today's builds (2003-03-24 Linux - built from CVS), UI and web pages don't
repaint when using Mozilla. If I switch to a different desktop or window and
back, it does show everything correctly though.
:hover effects don't work because of that as well.

I backed out smooth scrolling in my local tree, but that didn't help.
Duplicate of bug 197086?  (I haven't seen the problem, though.)
BTW, I still had a good tree when I pulled some time yesterday, so it really
must be something recent (yesterday's or today's checkins)...

the bad tree had
03/24/2003 02:17 - bmlk%gmx.de - mozilla/layout/html/style/src -
nsCSSRendering.cpp - +7/-2 - dont clip composite borders, bug 197086 r/sr=roc+moz
as its last checkin, so changes after this one can't be the cause.

dbaron: I don't think it's a dupe of bug 197086 as 1) it's quite recent, 2) the
fix for that was already in when I pulled...
I'll try backing out this one as well here...
I'm pretty sure that not everyone is seeing this, because some people have
downloaded builds to try smooth-scrolling, and they surely would have mentioned
this problem in that bug if they'd seen it.

It could be related to my patch for transparent chrome, which reorganized
double-buffering a little bit. If you have a debug build, are there any warnings
or assertions in the debug output?
roc:
sorry, no debug build here :(
anyways, I'm now trying to pull a tree before the transparency changes. If that
works, perhaps I should try to do a current clobber build? Or should I just
clobber a specific part of the tree?
Try downloading the latest build from ftp.mozilla.org and see if you see the
same problem with those bits.
I just discovered that this morning's nightly build crashes on startup on my
laptop at work. It works fine on my machine at home.

I ran valgrind on it and got this:

==19985== Invalid write of size 1
==19985==    at 0x425828C2: (within /home/roca/installed/test/mozilla/libgkgfx.so)
==19985==    by 0x425829D8: (within /home/roca/installed/test/mozilla/libgkgfx.so)
==19985==    by 0x42582B84: nsBlender::GetAlphas(nsRect const &, void *, void *,
unsigned char **)
(in /home/roca/installed/test/mozilla/libgkgfx.so)
==19985==    by 0x431D1FE7: (within
/home/roca/installed/test/mozilla/components/libgklayout.so)
==19985==    Address 0x47B72624 is 0 bytes after a block of size 10000 alloc'd
==19985==    at 0x40167DB8: __builtin_vec_new (vg_clientfuncs.c:163)
==19985==    by 0x42582B35: nsBlender::GetAlphas(nsRect const &, void *, void *,
unsigned char **)
(in /home/roca/installed/test/mozilla/libgkgfx.so)
==19985==    by 0x431D1FE7: (within
/home/roca/installed/test/mozilla/components/libgklayout.so)
==19985==    by 0x431D08FC: (within
/home/roca/installed/test/mozilla/components/libgklayout.so)
==19985== Warning: SIGSEGV not in user code; either from syscall kill()
==19985==    or possible Valgrind bug.  This message is only shown 3 times.

GetAlphas absolutely should not be being called because there's no transparent
chrome.

I'm going to attach a patch that disables transparent chrome for now.
I can't attach a patch because I'm having trouble contacting cvs.mozilla.org
(what a morning!)

Here's what needs to be done, I think:

          if (!parentDoc) {
            // our document is the root of the doc tree, so we must
            // either be a top-level XUL window or something embedded.
            // The SetWindowTranslucency call will fail if we're embedded.
            nsCOMPtr<nsIWidget> widget;
            aView->GetWidget(*getter_AddRefs(widget));
            if (widget) {
              // Enable translucency in the widget
!             NS_WARNING("Enabling window transparency");
!             // widget->SetWindowTranslucency(PR_TRUE);
!             // viewHasTransparentContent = PR_TRUE;
            }
          }

I'm not sure if this will show up on Netscape smoketests, because I don't see
this problem at home nor do the Tinderboxen seem to be affected.
Attached file backtrace, non-debug — 
Before I clobbered a current build it would hang or crash. After the clobber it
also hangs or crashes (when run in gdb). I get past the profile selector and
that's that.
OK, my problem is definately caused by bug 113232 (transparency patch).
I pulled a tree with MOZ_CO_DATE="2003-03-23 20:30 PST" (just before that one
landed), and it works OK.
The other one with bug 197086 and smooth scrolling back out (the two things that
landed after transparency) still had the problem.

I'll try a new build with the patch you inlined here...
BTW, here's buildconfig info about my build - perhaps some build arguments may
be the reason I'm seeing this (xft? svg?).

about:buildconfig

Build platform
target
i686-pc-linux-gnu

Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 3.2 	-Wall -W -Wno-unused -Wpointer-arith -Wcast-align
-pedantic -Wno-long-long -pthread -pipe
c++ 	gcc version 3.2 	-fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-pedantic -Wno-long-long -fshort-wchar -pthread -pipe -I/usr/X11R6/include

Configure arguments
--disable-tests --disable-bidi '--enable-optimize=-O2 -march=i686
-mcpu=pentiumpro' --enable-strip --enable-elf-dynstr-gc --disable-debug
--enable-crypto --enable-ldap --enable-mathml --enable-svg --enable-reorder
--enable-extensions=default --enable-chrome-format=both --enable-calendar
--enable-xft
darin was seeing something like this on linux.

darin, does this sound like your bug?
bug 198985 seems related
It appears my CVS-over-SSH access has been cut off this morning due to some
network configuration change at AOL. I will have to mess around with things to
go back to plaintext password. If I can even remember my password.

In the meantime, Seth, can you see if my patch fixes the problem and if so,
check it in? If that doesn't work, just back out the whole of the patch in bug
113232.
Which patch do you refer to in comment #13? The code in comment 7? Is that a
patch? Which file is it supposed to be in?
I'm going to try roc's patch in comment#7, as soon as my linux build is done (in
~30 mins)
when my build is done, I'll try the patch (unless suresh beats me too it.)
That patch was supposed to be in nsContainerFrame.cpp
In my linux debug build, I couldn't duplicate this problem :( 
almost done with my debug build, then I'll try, and then try roc's patch.
hm...that may also fix the other blocker bug 198983.
ok, without roc's fix, here's how I hit this bug on my debug linux build:

the mail password prompt is grey.  I have to resize to paint.

with the patch, the dialog paints.

roc, should I check in?
Assignee: blizzard → roc+moz
I've checked in roc's patch, as it fixes the problems I was seeing with alerts /
prompts not painting.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
the patch happens to also fix the crash in comment 8.
*** Bug 199016 has been marked as a duplicate of this bug. ***
*** Bug 199047 has been marked as a duplicate of this bug. ***
Adding topcrash info for future reference.  This was a topcrash with 3/24 Trunk
builds.
Keywords: crash, topcrash
Summary: repainting horribly broken → repainting horribly broken - Trunk [@ ComputeAlphasByByte]
Product: Core → Core Graveyard
Crash Signature: [@ ComputeAlphasByByte]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: