WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
125413
Can not handle combo boxes in Red Hat bugzilla
https://bugs.webkit.org/show_bug.cgi?id=125413
Summary
Can not handle combo boxes in Red Hat bugzilla
Debarshi Ray
Reported
2013-12-08 06:53:16 PST
Created
attachment 218686
[details]
reproducer For the last few releases (Fedora 18, Fedora 19 and Fedora 20), webkitgtk3 has been enable to deal with the giant combo boxes in the Red Hat bugzilla. You can see the CPU or memory usage soar, the application becomes unresponsive, and eventually crashes. It happens with both the WebKit1 (see attachment) and WebKit2 (when using Epiphany) APIs.
Attachments
reproducer
(1.98 KB, text/plain)
2013-12-08 06:53 PST
,
Debarshi Ray
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Debarshi Ray
Comment 1
2013-12-08 06:54:34 PST
To reproduce this behaviour, you must log in and try to use the combo box for "Component".
Claudio Saavedra
Comment 2
2013-12-08 07:21:11 PST
Looks like a duplicate with
https://bugs.webkit.org/show_bug.cgi?id=124671
Debarshi Ray
Comment 3
2013-12-08 15:45:42 PST
I have not tried master yet, but the situation appeas to be worse with 2.2.3 than it was with 2.2.2. With 2.2.2, it would start to misbehave when you actually tried to use the combo boxes after logging in, but now merely authenticating is enough to make it misbehave. CPU stays stuck at 100%, memory consumption soars and it eventually crashes with: (gdb) bt #0 SpanToMallocResult (span=<optimized out>, span=<optimized out>) at Source/WTF/wtf/FastMalloc.cpp:4025 #1 do_malloc<true> (size=<optimized out>) at Source/WTF/wtf/FastMalloc.cpp:4054 #2 fastMalloc<true> (size=<optimized out>) at Source/WTF/wtf/FastMalloc.cpp:4280 #3 WTF::fastMalloc (size=<optimized out>) at Source/WTF/wtf/FastMalloc.cpp:4243 #4 0x00007ffff62952c0 in allocateBuffer (newCapacity=<optimized out>, this=<error reading variable: Cannot access memory at address 0x7fffffffd198>) at Source/WTF/wtf/Vector.h:259 #5 reserveCapacity (newCapacity=<optimized out>, this=<error reading variable: Cannot access memory at address 0x7fffffffd198>) at Source/WTF/wtf/Vector.h:944 #6 expandCapacity (newMinCapacity=<error reading variable: Cannot access memory at address 0x7fffffffd1b0>, this=<error reading variable: Cannot access memory at address 0x7fffffffd198>) at Source/WTF/wtf/Vector.h:854 #7 expandCapacity<WebCore::AccessibilityMenuListOption* const> (ptr=<error reading variable: Cannot access memory at address 0x7fffffffd1a0>, newMinCapacity=<error reading variable: Cannot access memory at address 0x7fffffffd1b0>, this=<error reading variable: Cannot access memory at address 0x7fffffffd198>) at Source/WTF/wtf/Vector.h:892 #8 WTF::Vector<WTF::RefPtr<WebCore::AccessibilityObject>, 0ul, WTF::CrashOnOverflow>::appendSlowCase<WebCore::AccessibilityMenuListOption*> ( this=<error reading variable: Cannot access memory at address 0x7fffffffd198>, this@entry=0x7fff73f9e610, val=<error reading variable: Cannot access memory at address 0x7fffffffd1a0>) at Source/WTF/wtf/Vector.h:1058 #9 0x00007ffff629516b in append<WebCore::AccessibilityMenuListOption*> (val=@0x7fffffffd200: <error reading variable>, this=0x7fff73f9e610) at Source/WTF/wtf/Vector.h:1049 #10 WebCore::AccessibilityMenuListPopup::addChildren (this=0x7fff73f9e600) at Source/WebCore/accessibility/AccessibilityMenuListPopup.cpp:111
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug