Bug 125413 - Can not handle combo boxes in Red Hat bugzilla
Summary: Can not handle combo boxes in Red Hat bugzilla
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-08 06:53 PST by Debarshi Ray
Modified: 2017-03-11 11:00 PST (History)
2 users (show)

See Also:


Attachments
reproducer (1.98 KB, text/plain)
2013-12-08 06:53 PST, Debarshi Ray
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Debarshi Ray 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.
Comment 1 Debarshi Ray 2013-12-08 06:54:34 PST
To reproduce this behaviour, you must log in and try to use the combo box for "Component".
Comment 2 Claudio Saavedra 2013-12-08 07:21:11 PST
Looks like a duplicate with https://bugs.webkit.org/show_bug.cgi?id=124671
Comment 3 Debarshi Ray 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