Bug 65458 - REGRESSION(r92092): Build fails on 64 bit
Summary: REGRESSION(r92092): Build fails on 64 bit
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P1 Blocker
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 65437 65840
  Show dependency treegraph
 
Reported: 2011-08-01 02:49 PDT by Csaba Osztrogonác
Modified: 2011-08-07 23:17 PDT (History)
5 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Csaba Osztrogonác 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
Comment 1 Zoltan Herczeg 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?
Comment 2 Filip Pizlo 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...
Comment 3 Filip Pizlo 2011-08-01 14:16:30 PDT
Created attachment 102556 [details]
the patch

I believe that this is the more appropriate fix...
Comment 4 WebKit Review Bot 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>
Comment 5 WebKit Review Bot 2011-08-01 15:09:43 PDT
All reviewed patches have been landed.  Closing bug.
Comment 6 Zoltan Herczeg 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)