WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
65458
REGRESSION(
r92092
): Build fails on 64 bit
https://bugs.webkit.org/show_bug.cgi?id=65458
Summary
REGRESSION(r92092): Build fails on 64 bit
Csaba Osztrogonác
Reported
2011-08-01 02:49:27 PDT
After
r92092
the build fails on the 64 bit relase mode on Qt platform: cc1plus: warnings being treated as errors ../../../Source/JavaScriptCore/heap/Heap.h: In function ‘OpaqueJSContext* JSGlobalContextCreateInGroup(const OpaqueJSContextGroup*, OpaqueJSClass*)’: ../../../Source/JavaScriptCore/heap/Heap.h:319: error: array subscript is above array bounds ../../../Source/JavaScriptCore/heap/Heap.h:323: error: array subscript is above array bounds ../../../Source/JavaScriptCore/heap/Heap.h:319: error: array subscript is above array bounds ../../../Source/JavaScriptCore/heap/Heap.h:323: error: array subscript is above array bounds make[1]: *** [obj/release/JSContextRef.o] Error 1
Attachments
preliminary patch
(2.03 KB, patch)
2011-08-01 07:12 PDT
,
Zoltan Herczeg
no flags
Details
Formatted Diff
Diff
the patch
(2.53 KB, patch)
2011-08-01 14:16 PDT
,
Filip Pizlo
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Zoltan Herczeg
Comment 1
2011-08-01 07:12:46 PDT
Created
attachment 102514
[details]
preliminary patch This patch fixes the compile assert but it cause an infinite loop as it creates a block with cellSize 0. There is some hidden dependency between the blocks and values. Geoff, any idea?
Filip Pizlo
Comment 2
2011-08-01 13:24:16 PDT
(In reply to
comment #1
)
> Created an attachment (id=102514) [details] > preliminary patch > > This patch fixes the compile assert but it cause an infinite loop as it creates a block with cellSize 0. There is some hidden dependency between the blocks and values. > > Geoff, any idea?
The issue is with the logic in sizeClassFor(). The preciseCutoff is actually the smallest allocation size for imprecise size classes, rather than the upper bound on sizes for precise size classes. So for example in the current scheme, a 120 byte allocation should be allocated as 128 bytes, and so it should go to an imprecise size class. So the number of size classes is not wrong, but the selection algorithm is. I've got a patch for this and am testing it now...
Filip Pizlo
Comment 3
2011-08-01 14:16:30 PDT
Created
attachment 102556
[details]
the patch I believe that this is the more appropriate fix...
WebKit Review Bot
Comment 4
2011-08-01 15:09:38 PDT
Comment on
attachment 102556
[details]
the patch Clearing flags on attachment: 102556 Committed
r92146
: <
http://trac.webkit.org/changeset/92146
>
WebKit Review Bot
Comment 5
2011-08-01 15:09:43 PDT
All reviewed patches have been landed. Closing bug.
Zoltan Herczeg
Comment 6
2011-08-02 02:05:23 PDT
Hey Filip! Thank you for fixing this. Could you fix both comments as well: // [ 8, 16... 128 ) // [ 128, 256... 1024 ) (RS=me)
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