<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>34569</bug_id>
          
          <creation_ts>2010-02-04 03:15:22 -0800</creation_ts>
          <short_desc>Don&apos;t call CRASH() in fastMalloc and fastCalloc when the requested memory size is 0</short_desc>
          <delta_ts>2010-02-11 19:29:16 -0800</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>Web Template Framework</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>All</rep_platform>
          <op_sys>All</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          <blocked>33564</blocked>
          <everconfirmed>0</everconfirmed>
          <reporter name="Kwang Yul Seo">skyul</reporter>
          <assigned_to name="Nobody">webkit-unassigned</assigned_to>
          <cc>ap</cc>
    
    <cc>darin</cc>
    
    <cc>eric</cc>
    
    <cc>zoltan</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>187712</commentid>
    <comment_count>0</comment_count>
    <who name="Kwang Yul Seo">skyul</who>
    <bug_when>2010-02-04 03:15:22 -0800</bug_when>
    <thetext>With USE_SYSTEM_MALLOC=1, fastMalloc, fastCalloc and fastRealloc call CRASH() if the return value of malloc, calloc and realloc is 0. However, those functions can return 0 when the request size is 0.

From the libc manual of malloc,

&quot;If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free().&quot;

Though it seems malloc returns a unique pointer in most systems, 0 can be returned in some systems. For instance, BREW&apos;s MALLOC returns 0 when size is 0.

Add a check if the request size is 0 or not before calling CRASH(). As the condition is short-circuited, it adds no runtime overhead in usual allocation scenario.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>187715</commentid>
    <comment_count>1</comment_count>
      <attachid>48126</attachid>
    <who name="Kwang Yul Seo">skyul</who>
    <bug_when>2010-02-04 03:18:49 -0800</bug_when>
    <thetext>Created attachment 48126
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>187736</commentid>
    <comment_count>2</comment_count>
    <who name="Zoltan Horvath">zoltan</who>
    <bug_when>2010-02-04 04:25:42 -0800</bug_when>
    <thetext>The patch looks okay to me.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>187869</commentid>
    <comment_count>3</comment_count>
      <attachid>48126</attachid>
    <who name="Darin Adler">darin</who>
    <bug_when>2010-02-04 11:16:14 -0800</bug_when>
    <thetext>Comment on attachment 48126
Patch

I suspect higher level code depends on not getting 0 when a size of 0 is passed. A better fix may be to change the size from 0 to 1 on the BREW system.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>187901</commentid>
    <comment_count>4</comment_count>
      <attachid>48126</attachid>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2010-02-04 12:38:15 -0800</bug_when>
    <thetext>Comment on attachment 48126
Patch

I agree with Darin - even when using system malloc, FastMalloc should provide standardized behavior on all platforms.

Please also see bug 29026 which covers a related issue.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>188029</commentid>
    <comment_count>5</comment_count>
    <who name="Kwang Yul Seo">skyul</who>
    <bug_when>2010-02-04 17:27:27 -0800</bug_when>
    <thetext>(In reply to comment #3)
&gt; (From update of attachment 48126 [details])
&gt; I suspect higher level code depends on not getting 0 when a size of 0 is
&gt; passed. A better fix may be to change the size from 0 to 1 on the BREW system.

I agree, but I don&apos;t want to introduce size check on the BREW system because it adds additional overhead to every allocation. 

This isn&apos;t a BREW specific issue because malloc can return 0 in other systems too.

Why don&apos;t we simply retry when malloc(0) returns 0?

void* fastMalloc(size_t n)
{
    ASSERT(!isForbidden());

#if ENABLE(FAST_MALLOC_MATCH_VALIDATION)
    TryMallocReturnValue returnValue = tryFastMalloc(n);
    void* result;
    returnValue.getValue(result);
#else
    void* result = malloc(n);
#endif

    if (!result)
        // malloc(0) can return 0.
        // To make sure that fastMalloc never returns 0, increase the size
        // to 1 and try again. This introduces no additional overhead
        // in usual allocations.
        if (n)
            CRASH();
        else
            return fastMalloc(1);

    return result;
}

It adds no overhead because non zero size request never returns 0 unless allocation fails.

However, I am not sure what to do with realloc because realloc(p, 0) is equivalent to free(p). This is the exact duplicate of  https://bugs.webkit.org/show_bug.cgi?id=29026</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>188054</commentid>
    <comment_count>6</comment_count>
      <attachid>48192</attachid>
    <who name="Kwang Yul Seo">skyul</who>
    <bug_when>2010-02-04 19:53:58 -0800</bug_when>
    <thetext>Created attachment 48192
Patch

If malloc(0) returns NULL in fastMalloc, increase the size to 1 and retry. Do the same for fastCalloc.

Leave out fastRealloc as it seems there is no code which calls fastRealloc(p, 0) currently. This needs to be discussed further in https://bugs.webkit.org/show_bug.cgi?id=29026</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>188098</commentid>
    <comment_count>7</comment_count>
      <attachid>48192</attachid>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2010-02-04 23:56:15 -0800</bug_when>
    <thetext>Comment on attachment 48192
Patch

I don&apos;t see how checking after calling malloc is better than checking before calling it. Normal case just gets one more branch either way, but fastMalloc(0) is slower if you check after malloc returns 0.

We don&apos;t need to add the branch on platforms that don&apos;t return 0, please protect the new code with preprocessor checks. Any future port that runs into this can add themselves to the check.

&gt;         (WTF::fastRealloc):

You still had this in ChangeLog.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>188104</commentid>
    <comment_count>8</comment_count>
    <who name="Kwang Yul Seo">skyul</who>
    <bug_when>2010-02-05 00:17:53 -0800</bug_when>
    <thetext>(In reply to comment #7)
&gt; (From update of attachment 48192 [details])
&gt; I don&apos;t see how checking after calling malloc is better than checking before
&gt; calling it. Normal case just gets one more branch either way, but fastMalloc(0)
&gt; is slower if you check after malloc returns 0.
&gt; 

Checking after malloc is actually better than checking before calling it. fastMalloc(n!=0) returns non-NULL unless allocation fails, so &quot;if (!result)&quot; branch is not taken at all in normal case. 

malloc(0) or allocation failure take this branch and an additional check is performed. Because both are not frequent, I think this is okay.

&gt; We don&apos;t need to add the branch on platforms that don&apos;t return 0, please
&gt; protect the new code with preprocessor checks. Any future port that runs into
&gt; this can add themselves to the check.

I agree. I will add guards. 

&gt; 
&gt; &gt;         (WTF::fastRealloc):
&gt; 
&gt; You still had this in ChangeLog.

Ooops. Sorry for the mistake.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>188108</commentid>
    <comment_count>9</comment_count>
      <attachid>48210</attachid>
    <who name="Kwang Yul Seo">skyul</who>
    <bug_when>2010-02-05 00:35:09 -0800</bug_when>
    <thetext>Created attachment 48210
Patch

Put platform guards.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>188111</commentid>
    <comment_count>10</comment_count>
      <attachid>48210</attachid>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2010-02-05 01:30:43 -0800</bug_when>
    <thetext>Comment on attachment 48210
Patch

I now see what you&apos;re saying - there&apos;s already a branch for null result, so you are not adding one.

+        // malloc(0) can return 0 in some systems.
+        // To make sure that fastMalloc never returns 0,
+        // retry with fastMalloc(1).

Saying &quot;in some systems&quot; can be confusing. I&apos;d say &quot;Behavior of malloc(0) is implementation defined&quot;. Also, these lines are extremely short, there is no need to wrap comments like this.

r=me. Someone can fix these when landing, or you could submit a corrected patch for commit queue.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>188123</commentid>
    <comment_count>11</comment_count>
      <attachid>48216</attachid>
    <who name="Kwang Yul Seo">skyul</who>
    <bug_when>2010-02-05 02:19:37 -0800</bug_when>
    <thetext>Created attachment 48216
Patch

Change the comment as Alexey suggested. Thank you for reviewing!</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>188146</commentid>
    <comment_count>12</comment_count>
    <who name="Zoltan Horvath">zoltan</who>
    <bug_when>2010-02-05 04:29:31 -0800</bug_when>
    <thetext>Committed revision 54419.
http://trac.webkit.org/changeset/54419</thetext>
  </long_desc>
      
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>48126</attachid>
            <date>2010-02-04 03:18:49 -0800</date>
            <delta_ts>2010-02-04 19:53:58 -0800</delta_ts>
            <desc>Patch</desc>
            <filename>malloc.patch</filename>
            <type>text/plain</type>
            <size>2240</size>
            <attacher name="Kwang Yul Seo">skyul</attacher>
            
              <data encoding="base64">SW5kZXg6IEphdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2NyaXB0
Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDU0MzQwKQorKysgSmF2YVNjcmlwdENvcmUvQ2hhbmdl
TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMjkgQEAKKzIwMTAtMDItMDQgIEt3YW5nIFl1
bCBTZW8gIDxza3l1bEBjb21wYW55MTAwLm5ldD4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JP
RFkgKE9PUFMhKS4KKworICAgICAgICBEb24ndCBjYWxsIENSQVNIKCkgaW4gZmFzdE1hbGxvYywg
ZmFzdENhbGxvYyBhbmQgZmFzdFJlYWxsb2Mgd2hlbiB0aGUgcmVxdWVzdGVkIG1lbW9yeSBzaXpl
IGlzIDAKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTM0
NTY5CisKKyAgICAgICAgV2l0aCBVU0VfU1lTVEVNX01BTExPQz0xLCBmYXN0TWFsbG9jLCBmYXN0
Q2FsbG9jIGFuZCBmYXN0UmVhbGxvYyBjYWxsIENSQVNIKCkKKyAgICAgICAgaWYgdGhlIHJldHVy
biB2YWx1ZSBvZiBtYWxsb2MsIGNhbGxvYyBhbmQgcmVhbGxvYyBpcyAwLiBIb3dldmVyLCB0aG9z
ZQorICAgICAgICBmdW5jdGlvbnMgY2FuIHJldHVybiAwIHdoZW4gdGhlIHJlcXVlc3Qgc2l6ZSBp
cyAwLgorCisgICAgICAgIExpYmMgbWFudWFsIHNheXMsICJJZiBzaXplIGlzIDAsIHRoZW4gbWFs
bG9jKCkgcmV0dXJucyBlaXRoZXIgTlVMTCwKKyAgICAgICAgb3IgYSB1bmlxdWUgcG9pbnRlciB2
YWx1ZSB0aGF0IGNhbiBsYXRlciBiZSBzdWNjZXNzZnVsbHkgcGFzc2VkIHRvIGZyZWUoKS4iCisK
KyAgICAgICAgVGhvdWdoIGl0IHNlZW1zIG1hbGxvYyByZXR1cm5zIGEgdW5pcXVlIHBvaW50ZXIg
aW4gbW9zdCBzeXN0ZW1zLCAwIGNhbiBiZQorICAgICAgICByZXR1cm5lZCBpbiBzb21lIHN5c3Rl
bXMuIEZvciBpbnN0YW5jZSwgQlJFVydzIE1BTExPQyByZXR1cm5zIDAgd2hlbiBzaXplIGlzIDAu
CisKKyAgICAgICAgQWRkIGEgY2hlY2sgaWYgdGhlIHJlcXVlc3Qgc2l6ZSBpcyAwIG9yIG5vdCBi
ZWZvcmUgY2FsbGluZyBDUkFTSCgpLiBBcyB0aGUKKyAgICAgICAgY29uZGl0aW9uIGlzIHNob3J0
LWNpcmN1aXRlZCwgaXQgYWRkcyBubyBydW50aW1lIG92ZXJoZWFkIGluIHVzdWFsIGFsbG9jYXRp
b24KKyAgICAgICAgc2NlbmFyaW8uCisKKyAgICAgICAgKiB3dGYvRmFzdE1hbGxvYy5jcHA6Cisg
ICAgICAgIChXVEY6OmZhc3RNYWxsb2MpOgorICAgICAgICAoV1RGOjpmYXN0Q2FsbG9jKToKKyAg
ICAgICAgKFdURjo6ZmFzdFJlYWxsb2MpOgorCiAyMDEwLTAyLTA0ICBKZWRyemVqIE5vd2Fja2kg
IDxqZWRyemVqLm5vd2Fja2lAbm9raWEuY29tPgogCiAgICAgICAgIFJldmlld2VkIGJ5IFNpbW9u
IEhhdXNtYW5uLgpJbmRleDogSmF2YVNjcmlwdENvcmUvd3RmL0Zhc3RNYWxsb2MuY3BwCj09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT0KLS0tIEphdmFTY3JpcHRDb3JlL3d0Zi9GYXN0TWFsbG9jLmNwcAkocmV2aXNpb24gNTQz
MjIpCisrKyBKYXZhU2NyaXB0Q29yZS93dGYvRmFzdE1hbGxvYy5jcHAJKHdvcmtpbmcgY29weSkK
QEAgLTIzOSw3ICsyMzksNyBAQCB2b2lkKiBmYXN0TWFsbG9jKHNpemVfdCBuKSAKICAgICB2b2lk
KiByZXN1bHQgPSBtYWxsb2Mobik7CiAjZW5kaWYKIAotICAgIGlmICghcmVzdWx0KQorICAgIGlm
ICghcmVzdWx0ICYmIG4pCiAgICAgICAgIENSQVNIKCk7CiAgICAgcmV0dXJuIHJlc3VsdDsKIH0K
QEAgLTI3OSw3ICsyNzksNyBAQCB2b2lkKiBmYXN0Q2FsbG9jKHNpemVfdCBuX2VsZW1lbnRzLCBz
aXplCiAgICAgdm9pZCogcmVzdWx0ID0gY2FsbG9jKG5fZWxlbWVudHMsIGVsZW1lbnRfc2l6ZSk7
CiAjZW5kaWYKIAotICAgIGlmICghcmVzdWx0KQorICAgIGlmICghcmVzdWx0ICYmIG5fZWxlbWVu
dHMgJiYgZWxlbWVudF9zaXplKQogICAgICAgICBDUkFTSCgpOwogICAgIHJldHVybiByZXN1bHQ7
CiB9CkBAIC0zNDAsNyArMzQwLDcgQEAgdm9pZCogZmFzdFJlYWxsb2Modm9pZCogcCwgc2l6ZV90
IG4pCiAgICAgdm9pZCogcmVzdWx0ID0gcmVhbGxvYyhwLCBuKTsKICNlbmRpZgogCi0gICAgaWYg
KCFyZXN1bHQpCisgICAgaWYgKCFyZXN1bHQgJiYgbikKICAgICAgICAgQ1JBU0goKTsKICAgICBy
ZXR1cm4gcmVzdWx0OwogfQo=
</data>
<flag name="review"
          id="30744"
          type_id="1"
          status="-"
          setter="ap"
    />
    <flag name="commit-queue"
          id="30745"
          type_id="3"
          status="-"
          setter="ap"
    />
          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>48192</attachid>
            <date>2010-02-04 19:53:58 -0800</date>
            <delta_ts>2010-02-05 00:35:09 -0800</delta_ts>
            <desc>Patch</desc>
            <filename>FastMalloc.patch</filename>
            <type>text/plain</type>
            <size>2216</size>
            <attacher name="Kwang Yul Seo">skyul</attacher>
            
              <data encoding="base64">SW5kZXg6IEphdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2NyaXB0
Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDU0NDAwKQorKysgSmF2YVNjcmlwdENvcmUvQ2hhbmdl
TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMjcgQEAKKzIwMTAtMDItMDQgIEt3YW5nIFl1
bCBTZW8gIDxza3l1bEBjb21wYW55MTAwLm5ldD4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JP
RFkgKE9PUFMhKS4KKworICAgICAgICBEb24ndCBjYWxsIENSQVNIKCkgaW4gZmFzdE1hbGxvYyBh
bmQgZmFzdENhbGxvYyB3aGVuIHRoZSByZXF1ZXN0ZWQgbWVtb3J5IHNpemUgaXMgMAorICAgICAg
ICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MzQ1NjkKKworICAgICAg
ICBXaXRoIFVTRV9TWVNURU1fTUFMTE9DPTEsIGZhc3RNYWxsb2MgYW5kIGZhc3RDYWxsb2MgY2Fs
bCBDUkFTSCgpCisgICAgICAgIGlmIHRoZSByZXR1cm4gdmFsdWUgb2YgbWFsbG9jIGFuZCBjYWxs
b2MgaXMgMC4gSG93ZXZlciwgdGhvc2UKKyAgICAgICAgZnVuY3Rpb25zIGNhbiByZXR1cm4gMCB3
aGVuIHRoZSByZXF1ZXN0IHNpemUgaXMgMC4KKworICAgICAgICBMaWJjIG1hbnVhbCBzYXlzLCAi
SWYgc2l6ZSBpcyAwLCB0aGVuIG1hbGxvYygpIHJldHVybnMgZWl0aGVyIE5VTEwsCisgICAgICAg
IG9yIGEgdW5pcXVlIHBvaW50ZXIgdmFsdWUgdGhhdCBjYW4gbGF0ZXIgYmUgc3VjY2Vzc2Z1bGx5
IHBhc3NlZCB0byBmcmVlKCkuIgorCisgICAgICAgIFRob3VnaCBpdCBzZWVtcyBtYWxsb2MgcmV0
dXJucyBhIHVuaXF1ZSBwb2ludGVyIGluIG1vc3Qgc3lzdGVtcywgMCBjYW4gYmUKKyAgICAgICAg
cmV0dXJuZWQgaW4gc29tZSBzeXN0ZW1zLiBGb3IgaW5zdGFuY2UsIEJSRVcncyBNQUxMT0MgcmV0
dXJucyAwIHdoZW4gc2l6ZSBpcyAwLgorCisgICAgICAgIElmIG1hbGxvYyBvciBjYWxsb2MgcmV0
dXJucyAwIGR1ZSB0byBhbGxvY2F0aW9uIHNpemUsIGluY3JlYXNlIHRoZSBzaXplIHRvIDEgYW5k
IHRyeSBhZ2Fpbi4KKworICAgICAgICAqIHd0Zi9GYXN0TWFsbG9jLmNwcDoKKyAgICAgICAgKFdU
Rjo6ZmFzdE1hbGxvYyk6CisgICAgICAgIChXVEY6OmZhc3RDYWxsb2MpOgorICAgICAgICAoV1RG
OjpmYXN0UmVhbGxvYyk6CisKIDIwMTAtMDItMDQgIEdhdmluIEJhcnJhY2xvdWdoICA8YmFycmFj
bG91Z2hAYXBwbGUuY29tPgogCiAgICAgICAgIFJldmlld2VkIGJ5IE9saXZlciBIdW50LgpJbmRl
eDogSmF2YVNjcmlwdENvcmUvd3RmL0Zhc3RNYWxsb2MuY3BwCj09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIEphdmFT
Y3JpcHRDb3JlL3d0Zi9GYXN0TWFsbG9jLmNwcAkocmV2aXNpb24gNTQzNDcpCisrKyBKYXZhU2Ny
aXB0Q29yZS93dGYvRmFzdE1hbGxvYy5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTI0MCw3ICsyNDAs
MTUgQEAgdm9pZCogZmFzdE1hbGxvYyhzaXplX3QgbikgCiAjZW5kaWYKIAogICAgIGlmICghcmVz
dWx0KQotICAgICAgICBDUkFTSCgpOworICAgICAgICAvLyBtYWxsb2MoMCkgY2FuIHJldHVybiAw
IGluIHNvbWUgc3lzdGVtcy4KKyAgICAgICAgLy8gVG8gbWFrZSBzdXJlIHRoYXQgZmFzdE1hbGxv
YyBuZXZlciByZXR1cm5zIDAsIGluY3JlYXNlIHRoZSBzaXplCisgICAgICAgIC8vIHRvIDEgYW5k
IHRyeSBhZ2Fpbi4gVGhpcyBpbnRyb2R1Y2VzIG5vIGFkZGl0aW9uYWwgb3ZlcmhlYWQKKyAgICAg
ICAgLy8gaW4gdXN1YWwgYWxsb2NhdGlvbnMuCisgICAgICAgIGlmIChuKQorICAgICAgICAgICAg
Q1JBU0goKTsKKyAgICAgICAgZWxzZQorICAgICAgICAgICAgcmV0dXJuIGZhc3RNYWxsb2MoMSk7
CisKICAgICByZXR1cm4gcmVzdWx0OwogfQogCkBAIC0yODAsNyArMjg4LDExIEBAIHZvaWQqIGZh
c3RDYWxsb2Moc2l6ZV90IG5fZWxlbWVudHMsIHNpemUKICNlbmRpZgogCiAgICAgaWYgKCFyZXN1
bHQpCi0gICAgICAgIENSQVNIKCk7CisgICAgICAgIGlmIChuX2VsZW1lbnRzICYmIGVsZW1lbnRf
c2l6ZSkKKyAgICAgICAgICAgIENSQVNIKCk7CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHJl
dHVybiBmYXN0Q2FsbG9jKDEsIDEpOworCiAgICAgcmV0dXJuIHJlc3VsdDsKIH0KIAo=
</data>
<flag name="review"
          id="30832"
          type_id="1"
          status="-"
          setter="ap"
    />
    <flag name="commit-queue"
          id="30833"
          type_id="3"
          status="-"
          setter="ap"
    />
          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>48210</attachid>
            <date>2010-02-05 00:35:09 -0800</date>
            <delta_ts>2010-02-05 02:19:37 -0800</delta_ts>
            <desc>Patch</desc>
            <filename>FastMalloc.patch</filename>
            <type>text/plain</type>
            <size>2440</size>
            <attacher name="Kwang Yul Seo">skyul</attacher>
            
              <data encoding="base64">SW5kZXg6IEphdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2NyaXB0
Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDU0NDEyKQorKysgSmF2YVNjcmlwdENvcmUvQ2hhbmdl
TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMjcgQEAKKzIwMTAtMDItMDUgIEt3YW5nIFl1
bCBTZW8gIDxza3l1bEBjb21wYW55MTAwLm5ldD4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JP
RFkgKE9PUFMhKS4KKworICAgICAgICBEb24ndCBjYWxsIENSQVNIKCkgaW4gZmFzdE1hbGxvYyBh
bmQgZmFzdENhbGxvYyB3aGVuIHRoZSByZXF1ZXN0ZWQgbWVtb3J5IHNpemUgaXMgMAorICAgICAg
ICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MzQ1NjkKKworICAgICAg
ICBXaXRoIFVTRV9TWVNURU1fTUFMTE9DPTEsIGZhc3RNYWxsb2MgYW5kIGZhc3RDYWxsb2MgY2Fs
bCBDUkFTSCgpCisgICAgICAgIGlmIHRoZSByZXR1cm4gdmFsdWUgb2YgbWFsbG9jIGFuZCBjYWxs
b2MgaXMgMC4KKyAgICAgICAgCisgICAgICAgIEhvd2V2ZXIsIHRoZXNlIGZ1bmN0aW9ucyBjYW4g
cmV0dXJuIDAgd2hlbiB0aGUgcmVxdWVzdCBzaXplIGlzIDAuCisgICAgICAgIExpYmMgbWFudWFs
IHNheXMsICJJZiBzaXplIGlzIDAsIHRoZW4gbWFsbG9jKCkgcmV0dXJucyBlaXRoZXIgTlVMTCwK
KyAgICAgICAgb3IgYSB1bmlxdWUgcG9pbnRlciB2YWx1ZSB0aGF0IGNhbiBsYXRlciBiZSBzdWNj
ZXNzZnVsbHkgcGFzc2VkIHRvIGZyZWUoKS4iCisgICAgICAgIFRob3VnaCBtYWxsb2MgcmV0dXJu
cyBhIHVuaXF1ZSBwb2ludGVyIGluIG1vc3Qgc3lzdGVtcywKKyAgICAgICAgMCBjYW4gYmUgcmV0
dXJuZWQgaW4gc29tZSBzeXN0ZW1zLiBGb3IgaW5zdGFuY2UsIEJSRVcncyBNQUxMT0MgcmV0dXJu
cyAwCisgICAgICAgIHdoZW4gc2l6ZSBpcyAwLgorCisgICAgICAgIElmIG1hbGxvYyBvciBjYWxs
b2MgcmV0dXJucyAwIGR1ZSB0byBhbGxvY2F0aW9uIHNpemUsIGluY3JlYXNlIHRoZSBzaXplCisg
ICAgICAgIHRvIDEgYW5kIHRyeSBhZ2Fpbi4KKworICAgICAgICAqIHd0Zi9GYXN0TWFsbG9jLmNw
cDoKKyAgICAgICAgKFdURjo6ZmFzdE1hbGxvYyk6CisgICAgICAgIChXVEY6OmZhc3RDYWxsb2Mp
OgorCiAyMDEwLTAyLTA0ICBNYXJrIFJvd2UgIDxtcm93ZUBhcHBsZS5jb20+CiAKICAgICAgICAg
UmV2aWV3ZWQgYnkgVGltb3RoeSBIYXRjaGVyLgpJbmRleDogSmF2YVNjcmlwdENvcmUvd3RmL0Zh
c3RNYWxsb2MuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIEphdmFTY3JpcHRDb3JlL3d0Zi9GYXN0TWFsbG9j
LmNwcAkocmV2aXNpb24gNTQ0MDIpCisrKyBKYXZhU2NyaXB0Q29yZS93dGYvRmFzdE1hbGxvYy5j
cHAJKHdvcmtpbmcgY29weSkKQEAgLTIzOSw4ICsyMzksMTcgQEAgdm9pZCogZmFzdE1hbGxvYyhz
aXplX3QgbikgCiAgICAgdm9pZCogcmVzdWx0ID0gbWFsbG9jKG4pOwogI2VuZGlmCiAKLSAgICBp
ZiAoIXJlc3VsdCkKKyAgICBpZiAoIXJlc3VsdCkgeworI2lmIFBMQVRGT1JNKEJSRVdNUCkKKyAg
ICAgICAgLy8gbWFsbG9jKDApIGNhbiByZXR1cm4gMCBpbiBzb21lIHN5c3RlbXMuCisgICAgICAg
IC8vIFRvIG1ha2Ugc3VyZSB0aGF0IGZhc3RNYWxsb2MgbmV2ZXIgcmV0dXJucyAwLAorICAgICAg
ICAvLyByZXRyeSB3aXRoIGZhc3RNYWxsb2MoMSkuCisgICAgICAgIGlmICghbikKKyAgICAgICAg
ICAgIHJldHVybiBmYXN0TWFsbG9jKDEpOworI2VuZGlmCiAgICAgICAgIENSQVNIKCk7CisgICAg
fQorCiAgICAgcmV0dXJuIHJlc3VsdDsKIH0KIApAQCAtMjc5LDggKzI4OCwxOCBAQCB2b2lkKiBm
YXN0Q2FsbG9jKHNpemVfdCBuX2VsZW1lbnRzLCBzaXplCiAgICAgdm9pZCogcmVzdWx0ID0gY2Fs
bG9jKG5fZWxlbWVudHMsIGVsZW1lbnRfc2l6ZSk7CiAjZW5kaWYKIAotICAgIGlmICghcmVzdWx0
KQorICAgIGlmICghcmVzdWx0KSB7CisjaWYgUExBVEZPUk0oQlJFV01QKQorICAgICAgICAvLyBJ
ZiBlaXRoZXIgbl9lbGVtZW50cyBvciBlbGVtZW50X3NpemUgaXMgMCwKKyAgICAgICAgLy8gY2Fs
bG9jIGNhbiByZXR1cm4gMCBpbiBzb21lIHN5c3RlbXMuCisgICAgICAgIC8vIFRvIG1ha2Ugc3Vy
ZSB0aGF0IGZhc3RDYWxsb2MgbmV2ZXIgcmV0dXJucyAwLAorICAgICAgICAvLyByZXRyeSB3aXRo
IGZhc3RDYWxsb2MoMSwgMSkuCisgICAgICAgIGlmICghbl9lbGVtZW50cyB8fCAhZWxlbWVudF9z
aXplKQorICAgICAgICAgICAgcmV0dXJuIGZhc3RDYWxsb2MoMSwgMSk7CisjZW5kaWYKICAgICAg
ICAgQ1JBU0goKTsKKyAgICB9CisKICAgICByZXR1cm4gcmVzdWx0OwogfQogCg==
</data>
<flag name="review"
          id="30851"
          type_id="1"
          status="+"
          setter="ap"
    />
    <flag name="commit-queue"
          id="30852"
          type_id="3"
          status="-"
          setter="ap"
    />
          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>48216</attachid>
            <date>2010-02-05 02:19:37 -0800</date>
            <delta_ts>2010-02-05 04:28:07 -0800</delta_ts>
            <desc>Patch</desc>
            <filename>FastMalloc.patch</filename>
            <type>text/plain</type>
            <size>2430</size>
            <attacher name="Kwang Yul Seo">skyul</attacher>
            
              <data encoding="base64">SW5kZXg6IEphdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2NyaXB0
Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDU0NDE0KQorKysgSmF2YVNjcmlwdENvcmUvQ2hhbmdl
TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMjcgQEAKKzIwMTAtMDItMDUgIEt3YW5nIFl1
bCBTZW8gIDxza3l1bEBjb21wYW55MTAwLm5ldD4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JP
RFkgKE9PUFMhKS4KKworICAgICAgICBEb24ndCBjYWxsIENSQVNIKCkgaW4gZmFzdE1hbGxvYyBh
bmQgZmFzdENhbGxvYyB3aGVuIHRoZSByZXF1ZXN0ZWQgbWVtb3J5IHNpemUgaXMgMAorICAgICAg
ICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MzQ1NjkKKworICAgICAg
ICBXaXRoIFVTRV9TWVNURU1fTUFMTE9DPTEsIGZhc3RNYWxsb2MgYW5kIGZhc3RDYWxsb2MgY2Fs
bCBDUkFTSCgpCisgICAgICAgIGlmIHRoZSByZXR1cm4gdmFsdWUgb2YgbWFsbG9jIGFuZCBjYWxs
b2MgaXMgMC4KKyAgICAgICAgCisgICAgICAgIEhvd2V2ZXIsIHRoZXNlIGZ1bmN0aW9ucyBjYW4g
cmV0dXJuIDAgd2hlbiB0aGUgcmVxdWVzdCBzaXplIGlzIDAuCisgICAgICAgIExpYmMgbWFudWFs
IHNheXMsICJJZiBzaXplIGlzIDAsIHRoZW4gbWFsbG9jKCkgcmV0dXJucyBlaXRoZXIgTlVMTCwK
KyAgICAgICAgb3IgYSB1bmlxdWUgcG9pbnRlciB2YWx1ZSB0aGF0IGNhbiBsYXRlciBiZSBzdWNj
ZXNzZnVsbHkgcGFzc2VkIHRvIGZyZWUoKS4iCisgICAgICAgIFRob3VnaCBtYWxsb2MgcmV0dXJu
cyBhIHVuaXF1ZSBwb2ludGVyIGluIG1vc3Qgc3lzdGVtcywKKyAgICAgICAgMCBjYW4gYmUgcmV0
dXJuZWQgaW4gc29tZSBzeXN0ZW1zLiBGb3IgaW5zdGFuY2UsIEJSRVcncyBNQUxMT0MgcmV0dXJu
cyAwCisgICAgICAgIHdoZW4gc2l6ZSBpcyAwLgorCisgICAgICAgIElmIG1hbGxvYyBvciBjYWxs
b2MgcmV0dXJucyAwIGR1ZSB0byBhbGxvY2F0aW9uIHNpemUsIGluY3JlYXNlIHRoZSBzaXplCisg
ICAgICAgIHRvIDEgYW5kIHRyeSBhZ2Fpbi4KKworICAgICAgICAqIHd0Zi9GYXN0TWFsbG9jLmNw
cDoKKyAgICAgICAgKFdURjo6ZmFzdE1hbGxvYyk6CisgICAgICAgIChXVEY6OmZhc3RDYWxsb2Mp
OgorCiAyMDEwLTAyLTA0ICBNYXJrIFJvd2UgIDxtcm93ZUBhcHBsZS5jb20+CiAKICAgICAgICAg
UmV2aWV3ZWQgYnkgVGltb3RoeSBIYXRjaGVyLgpJbmRleDogSmF2YVNjcmlwdENvcmUvd3RmL0Zh
c3RNYWxsb2MuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIEphdmFTY3JpcHRDb3JlL3d0Zi9GYXN0TWFsbG9j
LmNwcAkocmV2aXNpb24gNTQ0MTQpCisrKyBKYXZhU2NyaXB0Q29yZS93dGYvRmFzdE1hbGxvYy5j
cHAJKHdvcmtpbmcgY29weSkKQEAgLTIzOSw4ICsyMzksMTYgQEAgdm9pZCogZmFzdE1hbGxvYyhz
aXplX3QgbikgCiAgICAgdm9pZCogcmVzdWx0ID0gbWFsbG9jKG4pOwogI2VuZGlmCiAKLSAgICBp
ZiAoIXJlc3VsdCkKKyAgICBpZiAoIXJlc3VsdCkgeworI2lmIFBMQVRGT1JNKEJSRVdNUCkKKyAg
ICAgICAgLy8gVGhlIGJlaGF2aW9yIG9mIG1hbGxvYygwKSBpcyBpbXBsZW1lbnRhdGlvbiBkZWZp
bmVkLgorICAgICAgICAvLyBUbyBtYWtlIHN1cmUgdGhhdCBmYXN0TWFsbG9jIG5ldmVyIHJldHVy
bnMgMCwgcmV0cnkgd2l0aCBmYXN0TWFsbG9jKDEpLgorICAgICAgICBpZiAoIW4pCisgICAgICAg
ICAgICByZXR1cm4gZmFzdE1hbGxvYygxKTsKKyNlbmRpZgogICAgICAgICBDUkFTSCgpOworICAg
IH0KKwogICAgIHJldHVybiByZXN1bHQ7CiB9CiAKQEAgLTI3OSw4ICsyODcsMTYgQEAgdm9pZCog
ZmFzdENhbGxvYyhzaXplX3Qgbl9lbGVtZW50cywgc2l6ZQogICAgIHZvaWQqIHJlc3VsdCA9IGNh
bGxvYyhuX2VsZW1lbnRzLCBlbGVtZW50X3NpemUpOwogI2VuZGlmCiAKLSAgICBpZiAoIXJlc3Vs
dCkKKyAgICBpZiAoIXJlc3VsdCkgeworI2lmIFBMQVRGT1JNKEJSRVdNUCkKKyAgICAgICAgLy8g
SWYgZWl0aGVyIG5fZWxlbWVudHMgb3IgZWxlbWVudF9zaXplIGlzIDAsIHRoZSBiZWhhdmlvciBv
ZiBjYWxsb2MgaXMgaW1wbGVtZW50YXRpb24gZGVmaW5lZC4KKyAgICAgICAgLy8gVG8gbWFrZSBz
dXJlIHRoYXQgZmFzdENhbGxvYyBuZXZlciByZXR1cm5zIDAsIHJldHJ5IHdpdGggZmFzdENhbGxv
YygxLCAxKS4KKyAgICAgICAgaWYgKCFuX2VsZW1lbnRzIHx8ICFlbGVtZW50X3NpemUpCisgICAg
ICAgICAgICByZXR1cm4gZmFzdENhbGxvYygxLCAxKTsKKyNlbmRpZgogICAgICAgICBDUkFTSCgp
OworICAgIH0KKwogICAgIHJldHVybiByZXN1bHQ7CiB9CiAK
</data>

          </attachment>
      

    </bug>

</bugzilla>