198502 - Scrolling back and forth in the text entry fields yields a Gdk-ERROR followed by a hang

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Dan Kegel]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314

Clicking and dragging the mouse to select text in one of the text
entry boxes often yields a Gdk-ERROR followed by a hang.
The error is highly repeatable sometimes, and requires lots of scrolling
back and forth others. 


Reproducible: Sometimes

Steps to Reproduce:
1. open http://www.kegel.com/bugframe.html
2. start selecing text in one of the text entry fields.  It often hangs as soon
as I've swept four characters.
3. if it doesn't hang right away, keep moving the mouse back and forth while
holding the button down.  Sometimes making the file local instead of loading
it from the web makes a difference?  I can crash 19 times out of 20.

Actual Results:  
Gdk-Error followed by full mozilla freeze


Here are the various error messages I've seen:

Gdk-ERROR **: BadRequest (invalid request code or no such operation)
  serial 3133 error_code 1 request_code 223 minor_code 0
Gdk-ERROR **: BadRequest (invalid request code or no such operation)
  serial 4054 error_code 1 request_code 196 minor_code 0
Gdk-ERROR **: BadColor (invalid Colormap parameter)
  serial 11085 error_code 12 request_code 91 minor_code 0
Gdk-ERROR **: BadRequest (invalid request code or no such operation)
  serial 8575 error_code 1 request_code 167 minor_code 0

Comment 1

[Dan Kegel]

Attachment: Stack traceback after hang

Comment 2

[Dan Kegel]

This bug was also present in Mozilla 1.3beta.
I am running Red Hat 8.0, using the Xft RPMs
from ftp.mozilla.org.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Ah, that's the key piece of data.  Over to blizzard.

Comment 4

[Dan Kegel]

Attachment: Stack traceback with gtk2 version of mozilla

Happens with the gtk2 version of the rh8 rpms, too.
New stack trace attached.

Comment 5

[Christopher Blizzard (:blizzard)]

Can you start the browser up with --sync and get a stack trace then?  I suspect
that you're getting a bogus stack trace there.

Comment 6

[Dan Kegel]

I reran with --sync and got a stack dump.  Interestingly,
the hang can be reproduced by scrolling in the URL
field of the browser, too, and I get the same stack dump there.

(gdb) bt
#0  0x420d3b2e in select () from /lib/i686/libc.so.6
#1  0x406ebb28 in _XlcPublicMethods () from /usr/X11R6/lib/libX11.so.6
#2  0x40642047 in _XRead () from /usr/X11R6/lib/libX11.so.6
#3  0x40642b67 in _XReply () from /usr/X11R6/lib/libX11.so.6
#4  0x4063e075 in XSync () from /usr/X11R6/lib/libX11.so.6
#5  0x403832dc in gdk_flush () from /usr/lib/libgdk-x11-2.0.so.0
#6  0x40375758 in gdk_window_process_all_updates () from
/usr/lib/libgdk-x11-2.0.so.0
#7  0x403757a1 in gdk_window_update_idle () from /usr/lib/libgdk-x11-2.0.so.0
#8  0x4049ac83 in g_idle_dispatch () from /usr/lib/libglib-2.0.so.0
#9  0x40497f65 in g_main_dispatch () from /usr/lib/libglib-2.0.so.0
#10 0x40498f98 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#11 0x404992ad in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0
#12 0x40499a1f in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#13 0x401d039f in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#14 0x40f456ac in nsAppShell::Run() () from
/usr/lib/mozilla-1.3/components/libwidget_gtk2.so
#15 0x40f23cee in nsAppShellService::Run() () from
/usr/lib/mozilla-1.3/components/libnsappshell.so
#16 0x0804e08e in main1(int, char**, nsISupports*) ()
#17 0x0804e725 in main ()
#18 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

Comment 7

[Andrew Schultz]

Dan: are you still seeing this bug with a recent build (1.7 or 1.8b1)?

Comment 8

[Dan Kegel]

I don't see it with 1.7.6.