12535 2007-02-01 13:23:01 -0800 Stack-optimizing compilers can trick GC into freeing in-use objects 2007-03-30 15:45:20 -0700 1 1 1 Unclassified WebKit JavaScriptCore 420+ PC Windows XP RESOLVED FIXED InRadar P1 Major --- 1 huanr huanr ap erowe fishd ggaren huanr ian.eng.webkit KwhiteRight oldest_to_newest 29120 0 huanr 2007-02-01 13:23:01 -0800 on windows platform, I observed quite a few crashes at kjs_pcre_exec(). the cause has been traced back to previous call at KJS::FunctionCallDotNode::evaluate -> KJS::StringImp::toObject -> KJS::StringInstance::StringInstance -> KJS::jsString where the garbage collector frees an object in use. This incorrect free casues memory corruption and leads to later crash at kjs_pcre_exec() 29122 1 ddkilzer 2007-02-01 13:37:23 -0800 Please post an example URL or a reduced test case to this bug. Thanks! Also, what are you using to test WebKit on Windows? Spinneret or another application? 29123 2 huanr 2007-02-01 13:49:51 -0800 the bug repros randomly as it depends on when GC is invoked. my proposed fix is in kjs::FunctionCallDotNode::evaluate JSValue *FunctionCallDotNode::evaluate(ExecState *exec) { JSValue *baseVal = base->evaluate(exec); // // In the optimized release build, the compiler may discard the reference // to baseObj immediately after it resolves the address of // baseVal->toObject(). This makes baseVal subject to garbage collection // inside baseVal->toObject(). // If the runtime type of baseVal is StringImp, StringImp::toObject() will // invoke a chain of function calls that allocate new objects while passing // its member variable val (type UString) as a parameter. // If Garbage Collector is triggered during memory allocation, baseVal is // deleted and thus its member val, which is passed as a parameter, becomes // invalid. When newly created object references val, we will have memory // corruption. // Collector::protect(baseVal); JSObject *baseObj = baseVal->toObject(exec); Collector::unprotect(baseVal); ... 29127 3 ian.eng.webkit 2007-02-01 14:55:38 -0800 The is caused by a general unsafe practice in KJS code: take the address of a field in a JSCell object, and passed it around. For example: in KJS internal.h class StringImp : public JSCell { private: UString val; } In StringImp::toObject(ExecState* exec);, val is passed as a reference to the constructor StringInstance::StringInstance. Unfortunately, the compiler was smart enough that it thought this pointer is not used anymore, and put it in a volatile register. The constructor triggers GC, and this object is freed. Now the address of 'val' points to an invalid address. The problem is that the garbage collector only compares pointers to the start address of JSCell's. If there is a pointer to the middle of a JSCell, it won't be traced. One partial fix I'd suggest is to treat a JSCell as live if there is a root pointer pointing to its body. This will allow taking addresses of a field in a JSCell and passing it to stack/local variables. BUT this cannot solve the problem when such an address is assigned to somewhere in the heap. Comments? 29131 4 ggaren 2007-02-01 15:12:47 -0800 (In reply to comment #2) Anrong, did you mean to say that the compiler may discard the reference to 'baseObj' or to 'baseVal'? Your reasoning points to 'baseVal', not 'baseObj'. Would this bug persist if toObject() made use of 'this', prohibiting the compiler from optimizing out baseVal? I don't think 'Collector::protect(baseVal);' is a very good solution. It's inefficient, and it doesn't seem to address the root cause of the problem, which may affect lots of different parts of the code. 29132 5 ggaren 2007-02-01 15:23:28 -0800 (In reply to comment #3) I don't think pointers in the (non-GC) heap are a consideration. You already have to protect them explicitly. Honoring pointers to object bodies as pointers to the objects themselves seems like it would solve the problem. I worry that it might increase marking overhead substantially because we would start honoring more 'fake' pointers. Another solution would be for objects to create an explicit, volatile stack reference to 'this' before handing off pointers to their internals. Yet another solution (in this particular case) would be to store a temporary UString on the stack, and pass that UString by reference. 29135 6 ian.eng.webkit 2007-02-01 16:07:37 -0800 (In reply to comment #5) > (In reply to comment #3) > > I don't think pointers in the (non-GC) heap are a consideration. You already > have to protect them explicitly. > > Honoring pointers to object bodies as pointers to the objects themselves seems > like it would solve the problem. I worry that it might increase marking > overhead substantially because we would start honoring more 'fake' pointers. I think the overhead might no much. Instead of checking if (offset % sizeof(CollectorCell) == 0) It does some arithmatic calculation: x = cellStart + (offset / sizeof(CollectorCell)) * sizeof(CollectorCell); We need some additional work for oversized cells. Size infomation is needed. We can malloc an additional int before the requested size, and store the cell size into it. This works like a Java array with length in its header. BTW, I experimented this change, and it works properly. Overall, these only cost a few instruction cycles when scanning root pointers. I think it is not a big issue. I will post a patch later. > > Another solution would be for objects to create an explicit, volatile stack > reference to 'this' before handing off pointers to their internals. Yet another > solution (in this particular case) would be to store a temporary UString on the > stack, and pass that UString by reference. > (In reply to comment #5) > (In reply to comment #3) > > I don't think pointers in the (non-GC) heap are a consideration. You already > have to protect them explicitly. > > Honoring pointers to object bodies as pointers to the objects themselves seems > like it would solve the problem. I worry that it might increase marking > overhead substantially because we would start honoring more 'fake' pointers. > > Another solution would be for objects to create an explicit, volatile stack > reference to 'this' before handing off pointers to their internals. Yet another > solution (in this particular case) would be to store a temporary UString on the > stack, and pass that UString by reference. > 29139 7 12864 ian.eng.webkit 2007-02-01 16:53:43 -0800 Created attachment 12864 trace pointers into bodies The patch doesn't following the format required by webkit.org, I put it here for discussion. 29141 8 mjs 2007-02-01 17:23:39 -0800 (In reply to comment #6) > > > Honoring pointers to object bodies as pointers to the objects themselves seems > > like it would solve the problem. I worry that it might increase marking > > overhead substantially because we would start honoring more 'fake' pointers. > > I think the overhead might no much. Instead of checking > if (offset % sizeof(CollectorCell) == 0) > It does some arithmatic calculation: > x = cellStart + (offset / sizeof(CollectorCell)) * sizeof(CollectorCell); > > We need some additional work for oversized cells. Size infomation is needed. We > can malloc an additional int before the requested size, and store the cell size > into it. This works like a Java array with length in its header. BTW, I > experimented this change, and it works properly. > > Overall, these only cost a few instruction cycles when scanning root pointers. > I think it is not a big issue. The problem isn't the extra instructions to do the math. It's the cost of extra false positives. Note that right now before scanning the blocks we check: if (IS_CELL_ALIGNED(x) && x) { IS_CELL_ALIGNED checks for 8-byte alignment, which is not valid if we want to honor arbitrary pointers into object bodies. If we checked every nonzero value on the stack, we would do the block loop a lot more, which would be a significant performance regression. 29143 9 huanr 2007-02-01 18:07:28 -0800 (In reply to comment #4) > (In reply to comment #2) > > Anrong, did you mean to say that the compiler may discard the reference to > 'baseObj' or to 'baseVal'? Your reasoning points to 'baseVal', not 'baseObj'. > Would this bug persist if toObject() made use of 'this', prohibiting the > compiler from optimizing out baseVal? > > I don't think 'Collector::protect(baseVal);' is a very good solution. It's > inefficient, and it doesn't seem to address the root cause of the problem, > which may affect lots of different parts of the code. > Geoffrey, I meant baseVal. The bug goes away if toObject() made use of 'this' thus effectively lock baseVal. Collector::protect(baseVal) fixes this code path. if this is a common pattern then other solutions being discussed here may be better if they have no global impact. 29162 10 huanr 2007-02-01 22:07:47 -0800 (In reply to comment #9) > (In reply to comment #4) > > (In reply to comment #2) > > > > Anrong, did you mean to say that the compiler may discard the reference to > > 'baseObj' or to 'baseVal'? Your reasoning points to 'baseVal', not 'baseObj'. > > Would this bug persist if toObject() made use of 'this', prohibiting the > > compiler from optimizing out baseVal? > > > > I don't think 'Collector::protect(baseVal);' is a very good solution. It's > > inefficient, and it doesn't seem to address the root cause of the problem, > > which may affect lots of different parts of the code. > > > > Geoffrey, > > I meant baseVal. The bug goes away if toObject() made use of 'this' thus > effectively lock baseVal. > Collector::protect(baseVal) fixes this code path. if this is a common pattern > then other solutions being discussed here may be better if they have no global > impact. > The following fix has also been verified: #if COMPILER(MSVC) #pragma optimize("", off) #endif JSObject *StringImp::toObject(ExecState *exec) const { const StringImp *ptr = this; return new StringInstance(exec->lexicalInterpreter()->builtinStringPrototype(), ptr->val); } #if COMPILER(MSVC) #pragma optimize("", on) #endif I agree this fix is better than Collector::protect as it addresses all calling path. Turning off optimization has little cost here since the function is simple enough. (It turns out the compiler will optimize the variable away even we declare the local to be volatile) I could provide the patch. 29164 11 ggaren 2007-02-01 22:50:36 -0800 Is that really the only function hit by this bug? 29220 12 ian.eng.webkit 2007-02-02 11:14:58 -0800 (In reply to comment #8) > (In reply to comment #6) > > > > > Honoring pointers to object bodies as pointers to the objects themselves seems > > > like it would solve the problem. I worry that it might increase marking > > > overhead substantially because we would start honoring more 'fake' pointers. > > > > I think the overhead might no much. Instead of checking > > if (offset % sizeof(CollectorCell) == 0) > > It does some arithmatic calculation: > > x = cellStart + (offset / sizeof(CollectorCell)) * sizeof(CollectorCell); > > > > We need some additional work for oversized cells. Size infomation is needed. We > > can malloc an additional int before the requested size, and store the cell size > > into it. This works like a Java array with length in its header. BTW, I > > experimented this change, and it works properly. > > > > Overall, these only cost a few instruction cycles when scanning root pointers. > > I think it is not a big issue. > > The problem isn't the extra instructions to do the math. It's the cost of extra > false positives. Note that right now before scanning the blocks we check: > > if (IS_CELL_ALIGNED(x) && x) { > > IS_CELL_ALIGNED checks for 8-byte alignment, which is not valid if we want to > honor arbitrary pointers into object bodies. > > If we checked every nonzero value on the stack, we would do the block loop a > lot more, which would be a significant performance regression. > Maciej, is there a performance test suite to measure how much overhead it would be? Maybe we can think about using a interval tree instead of the block loop to speed up the range test. Another solution is to fix these classes returning field addresses. It may not be hard to do, but it cannot prevent violations in the future. 29222 13 huanr 2007-02-02 11:18:25 -0800 (In reply to comment #11) > Is that really the only function hit by this bug? > StringImp::toObject is the only one I discovered during debugging. Is passing member variables of JSCell in function call a common pattern in kjs?. I did a quick search on other toObject() functions under JavaScriptCore/kjs and did not find this issue. 28997 14 ap 2007-02-03 03:50:18 -0800 > #if COMPILER(MSVC) > #pragma optimize("", off) > #endif Is there a more cross-platform way to defeat the stack re-use? Perhaps coping the value into memory allocated by alloca() could help. 27711 15 mjs 2007-02-04 11:36:33 -0800 We use JavaScript iBench (not publicly available) and the 24fun BenchJs benchmark: http://www.24fun.com/downloadcenter/benchjs/benchjs.html I'm happy to performance test any proposed patch. 27649 16 mjs 2007-02-04 11:49:26 -0800 <rdar://problem/4975127> 27450 17 huanr 2007-02-05 10:53:21 -0800 (In reply to comment #14) > > #if COMPILER(MSVC) > > #pragma optimize("", off) > > #endif > > Is there a more cross-platform way to defeat the stack re-use? Perhaps coping > the value into memory allocated by alloca() could help. > If we use alloca(), there is still a possibility that the compiler may optimize it away, just like what it does to baseVal described earlier. There seems no gruantee to prevent all compilers from doing that. For compilers used on other platform, we can consider also using pragma to turn off optimization, probably with different syntax, for this funciton if needed. 27396 18 ian.eng.webkit 2007-02-05 11:30:12 -0800 (In reply to comment #13) > (In reply to comment #11) > > Is that really the only function hit by this bug? > > > > StringImp::toObject is the only one I discovered during debugging. Is > passing member variables of JSCell in function call a common pattern in kjs?. I > did a quick search on other toObject() functions under JavaScriptCore/kjs and > did not find this issue. > I sent my reply to Mark. Here is it again: Please correct me if I am wrong. A member function returning the address of/a reference to a field could also be a violator. I found a few cases: class InternalFunctionImp const Identifier& functionName() const { return m_name; } private: Identifier m_name; class Identifier { const UString& ustring() const { return _ustring; } private: UString _ustring; } One can write some code like: InternalFunctionImpl* func = new InternalFunctionImpl(); Identifier* id = func->functionName(); UString* v = id->ustring(); func = NULL; // trigger GC here // now id and v points to invalid memory Other similar cases: class FunctionImpl: const ScopeChain& scope() const { return _scope; } private: ScopeChain _scope; I went through these files so far. 27343 19 12947 ian.eng.webkit 2007-02-05 14:16:38 -0800 Created attachment 12947 a patch for preformance test Maciej, I created this patch by using svn-create-patch script. Please use this patch to measure the performance on benchmarks you have. New code can be turned on/off by changing the value of ALLOW_INNER_POINTERS to 1/0. 25382 20 12947 mjs 2007-02-07 00:48:02 -0800 Comment on attachment 12947 a patch for preformance test Flagging review? for someone at Apple (probably me) to perf-test this. 24537 21 mjs 2007-02-09 18:10:32 -0800 I measured and this patch causes a 2% performance regression on the iBench, at least on Mac OS X (where it is not even needed since the compiler won't optimize out object pointers like that). I think this needs to be addressed more along the lines of Anrong Hu's approach, where we keep the compiler from dropping the pointer. I think copying to alloca()'d memory, or even just keeping it in a struct on the stack might do it, and something that works for current MSVC seems good enough. 24532 22 12947 mjs 2007-02-09 22:46:12 -0800 Comment on attachment 12947 a patch for preformance test r- for reasons stated above 24334 23 ian.eng.webkit 2007-02-10 22:19:24 -0800 (In reply to comment #21) > I measured and this patch causes a 2% performance regression on the iBench, at > least on Mac OS X (where it is not even needed since the compiler won't > optimize out object pointers like that). I think this needs to be addressed > more along the lines of Anrong Hu's approach, where we keep the compiler from > dropping the pointer. I think copying to alloca()'d memory, or even just > keeping it in a struct on the stack might do it, and something that works for > current MSVC seems good enough. > I am fine with Anrong's approach, but that won't cure the problem. What about another solution: fixing classes that return the address/a reference to a field? Like I mentioned in Comment #18, a method can return the value instead of a reference/address of the field. 23177 24 huanr 2007-02-15 12:41:43 -0800 (In reply to comment #23) > (In reply to comment #21) > > I measured and this patch causes a 2% performance regression on the iBench, at > > least on Mac OS X (where it is not even needed since the compiler won't > > optimize out object pointers like that). I think this needs to be addressed > > more along the lines of Anrong Hu's approach, where we keep the compiler from > > dropping the pointer. I think copying to alloca()'d memory, or even just > > keeping it in a struct on the stack might do it, and something that works for > > current MSVC seems good enough. > > > > I am fine with Anrong's approach, but that won't cure the problem. What about > another solution: fixing classes that return the address/a reference to a > field? > Like I mentioned in Comment #18, a method can return the value instead of a > reference/address of the field. > I will submit a fix. 23179 25 huanr 2007-02-15 13:15:26 -0800 (In reply to comment #24) > (In reply to comment #23) > > (In reply to comment #21) > > > I measured and this patch causes a 2% performance regression on the iBench, at > > > least on Mac OS X (where it is not even needed since the compiler won't > > > optimize out object pointers like that). I think this needs to be addressed > > > more along the lines of Anrong Hu's approach, where we keep the compiler from > > > dropping the pointer. I think copying to alloca()'d memory, or even just > > > keeping it in a struct on the stack might do it, and something that works for > > > current MSVC seems good enough. > > > > > > > I am fine with Anrong's approach, but that won't cure the problem. What about > > another solution: fixing classes that return the address/a reference to a > > field? > > Like I mentioned in Comment #18, a method can return the value instead of a > > reference/address of the field. > > > > > I will submit a fix. > I'd like to assign this bug to me. There are also other cross-platform p1 bugs I want to investigate. Is there a way to assign bugs to myself through Bugzilla? 23184 26 ggaren 2007-02-15 14:17:24 -0800 I think you can just use the "Reassign" radio button. 22769 27 mjs 2007-02-20 00:36:46 -0800 Returning a value instead of a pointer into the object seems fine. We should probably document that as a rule. 22776 28 erowe 2007-02-20 01:17:58 -0800 Honoring pointers to object bodies as pointers to the objects themselves would solve THIS problem but not the general class of issues. Imagine if rather than passing a reference to a member UString to jsString() we were passing a file handle, or a raw pointer (that needs to be deleted) or basically any sort of state whose lifetime is bound to the JSValue and which is not a pointer into the JSValue's memory. In any of these cases, the compiler would still optimize away any pointer to the object or its body, and we'd still have the problem. (In reply to comment #5) > (In reply to comment #3) > I don't think pointers in the (non-GC) heap are a consideration. You already > have to protect them explicitly. > Honoring pointers to object bodies as pointers to the objects themselves seems > like it would solve the problem. I worry that it might increase marking > overhead substantially because we would start honoring more 'fake' pointers. > Another solution would be for objects to create an explicit, volatile stack > reference to 'this' before handing off pointers to their internals. Yet another > solution (in this particular case) would be to store a temporary UString on the > stack, and pass that UString by reference. 20259 29 13507 huanr 2007-03-06 22:38:40 -0800 Created attachment 13507 Proposing fix A more cross-platform fix as suggested: using alloca() and putting the object reference onto stack. 20202 30 13507 mjs 2007-03-07 00:36:31 -0800 Comment on attachment 13507 Proposing fix 1) This will break the build on mac and linux since they call it alloca() not _alloca() and prototype it in alloca.h, not malloc.h. Please fix that. 2) Is this definitely the only place affected? It looks like further up in the comments, Ian Eng identified more potential trouble spots. 3) To fix just this one particular case, wouldn't it be simpler to just copy val to a local UString variable on the stack? That avoids relying on something unportable like alloca(). UString valCopy = val; return new StringInstance(exec->lexicalInterpreter()->builtinStringPrototype(), valCopy); r- to at least address comment 1, since this will break the build otherwise. 20036 31 13519 huanr 2007-03-07 11:33:41 -0800 Created attachment 13519 Fix 20037 32 huanr 2007-03-07 11:34:38 -0800 (In reply to comment #31) > Created an attachment (id=13519) [edit] > Fix > Re: (2) As a recap, the calling pattern that makes this happen is: A->B->C. (a) In A, the reference to B is optimized away. (b) In B, its data member is passed as parameter to C. (c) C does sth that may trigger gc, and then accesses B's member. Condition (b) is the culprit, and exists in other places in the code base. Ian identified some of them along the discussion. A crash needs all of (a), (b), (c) and this place is the only one we discovered so far. I'd think we just fix this crash now while looking for long term solution to address (b) in general. The step towards general solution, which I am looking into, is finding all instances of (b) so we have a better understanding of the scope of the problem. Re: (1), (3) So alloca is not portable either. (3) works as I verified it although future version of compiler might still optimize the reference away. Using MSVC macro works with all versions of VC compiler but it is platform dependent. (3) seems to be the best for now. New patch attached. 20031 33 13519 mjs 2007-03-07 11:36:52 -0800 Comment on attachment 13519 Fix r=me (although the ChangeLog comment is wrong now in mentioning alloca). 19869 34 mrowe 2007-03-07 17:57:55 -0800 Landed in r20043. Can you please ensure that your ChangeLog entries use spaces rather than tabs for indentation in future. 16424 35 ian.eng.webkit 2007-03-30 15:45:20 -0700 (In reply to comment #27) > Returning a value instead of a pointer into the object seems fine. We should > probably document that as a rule. > Saw this bug in another platform using a stocked version of webkit. The compiler in use is GCC for Linux. Exact the same place. I missed the case in comment #18 when a member field address of 'this' is passed to a callee. 'This' pointer is optimized away and 'this' object is considered as dead by GC. GC is triggered in the callee. Solution I mentioned in comment #18 won't fix this problem. 12864 2007-02-01 16:53:43 -0800 2007-02-05 14:16:38 -0800 trace pointers into bodies collector.cpp.diff text/plain 2147 ian.eng.webkit MTM4LDEzOWMxMzgsMTQ1DQo8ICAgICB2b2lkICpuZXdDZWxsID0gZmFzdE1hbGxvYyhzKTsNCjwg ICAgIGhlYXAub3ZlcnNpemVDZWxsc1t1c2VkT3ZlcnNpemVDZWxsc10gPSBzdGF0aWNfY2FzdDxD b2xsZWN0b3JDZWxsICo+KG5ld0NlbGwpOw0KLS0tDQo+ICAgICAvLyBhbGxvY2F0ZSBhbiBleHRy YSBsZW5ndGggZmllbGQgYXQgdGhlIGJlZ2lubmluZw0KPiAgICAgc2l6ZV90KiByYXdNZW0gPSBz dGF0aWNfY2FzdDxzaXplX3QqPihmYXN0TWFsbG9jKHMgKyBzaXplb2Yoc2l6ZV90KSkpOw0KPiAg ICAgLy8gc2hvdWxkIHdlIGNoZWNrIGlmIHRoZSBhbGxvY2F0aW9uIGZhaWxlZD8gPz8/DQo+ICAg ICAvLyBzYXZlIHRoZSBsZW5ndGggb2YgdGhlIGNlbGwgKGV4Y2x1ZGluZyB0aGUgbGVuZ3RoIGZp ZWxkIGl0c2VsZikNCj4gICAgICpyYXdNZW0gPSBzOw0KPiAgICAgdm9pZCogbmV3Q2VsbCA9IHJl aW50ZXJwcmV0X2Nhc3Q8dm9pZCo+KHJhd01lbSArIDEpOw0KPiANCj4gICAgIGhlYXAub3ZlcnNp emVDZWxsc1t1c2VkT3ZlcnNpemVDZWxsc10gPSByZWludGVycHJldF9jYXN0PENvbGxlY3RvckNl bGwgKj4obmV3Q2VsbCk7DQoyNzVjMjgxLDI4Mg0KPCAgIGNvbnN0IHNpemVfdCBsYXN0Q2VsbE9m ZnNldCA9IHNpemVvZihDb2xsZWN0b3JDZWxsKSAqIChDRUxMU19QRVJfQkxPQ0sgLSAxKTsNCi0t LQ0KPiAgIGNvbnN0IHNpemVfdCBjZWxsU2l6ZSA9IHNpemVvZihDb2xsZWN0b3JDZWxsKTsNCj4g ICBjb25zdCBzaXplX3QgbGFzdENlbGxPZmZzZXQgPSBjZWxsU2l6ZSAqIChDRUxMU19QRVJfQkxP Q0sgLSAxKTsNCjI3OWMyODYNCjwgICAgIGlmIChJU19DRUxMX0FMSUdORUQoeCkgJiYgeCkgew0K LS0tDQo+ICAgICBpZiAoSVNfUE9JTlRFUl9BTElHTkVEKHgpICYmIHgpIHsNCjI4MSwyODJjMjg4 LDI5Mg0KPCAgICAgICAgIHNpemVfdCBvZmZzZXQgPSB4IC0gcmVpbnRlcnByZXRfY2FzdDxjaGFy ICo+KGJsb2Nrc1tibG9ja10pOw0KPCAgICAgICAgIGlmIChvZmZzZXQgPD0gbGFzdENlbGxPZmZz ZXQgJiYgb2Zmc2V0ICUgc2l6ZW9mKENvbGxlY3RvckNlbGwpID09IDApDQotLS0NCj4gICAgICAg ICBjaGFyKiBibG9ja1N0YXJ0ID0gcmVpbnRlcnByZXRfY2FzdDxjaGFyKj4oYmxvY2tzW2Jsb2Nr XSk7DQo+ICAgICAgICAgc2l6ZV90IG9mZnNldCA9IHggLSBibG9ja1N0YXJ0Ow0KPiAgICAgICAg IGlmIChvZmZzZXQgPD0gbGFzdENlbGxPZmZzZXQpIHsNCj4gICAgICAgICAgIC8vIHggbWF5IHBv aW50IHRvIGNlbGwgYm9kaWVzLCBhZGp1c3QgaXQgdG8gdGhlIGNlbGwgaGVhZGVyLg0KPiAgICAg ICAgICAgeCA9IGJsb2NrU3RhcnQgKyAob2Zmc2V0IC8gY2VsbFNpemUpICogY2VsbFNpemU7DQoy ODNhMjk0DQo+ICAgICAgICAgfQ0KMjg1LDI4NmMyOTYsMzAyDQo8ICAgICAgIGZvciAoc2l6ZV90 IGkgPSAwOyBpICE9IHVzZWRPdmVyc2l6ZUNlbGxzOyBpKyspDQo8ICAgICAgICAgaWYgKHggPT0g cmVpbnRlcnByZXRfY2FzdDxjaGFyICo+KG92ZXJzaXplQ2VsbHNbaV0pKQ0KLS0tDQo+ICAgICAg IGZvciAoc2l6ZV90IGkgPSAwOyBpICE9IHVzZWRPdmVyc2l6ZUNlbGxzOyBpKyspIHsNCj4gICAg ICAgICAvLyByZWFkIHRoZSBsZW5ndGggaW5mb3JtYXRpb24gZnJvbSB0aGUgaGVhZGVyLg0KPiAg ICAgICAgIGNoYXIqIGNlbGxTdGFydCA9IHJlaW50ZXJwcmV0X2Nhc3Q8Y2hhcio+KG92ZXJzaXpl Q2VsbHNbaV0pOw0KPiAgICAgICAgIHNpemVfdCBsZW5ndGggPSAqKHJlaW50ZXJwcmV0X2Nhc3Q8 c2l6ZV90Kj4oY2VsbFN0YXJ0KSAtIDEpOw0KPiAgICAgICAgIGNoYXIqIGNlbGxFbmQgPSBjZWxs U3RhcnQgKyBsZW5ndGg7DQo+ICAgICAgICAgaWYgKGNlbGxTdGFydCA8PSB4ICYmIHggPCBjZWxs RW5kKSB7DQo+ICAgICAgICAgICB4ID0gY2VsbFN0YXJ0Ow0KMjg3YTMwNCwzMDUNCj4gICAgICAg ICB9DQo+ICAgICAgIH0NCjU3N2M1OTUsNTk3DQo8ICAgICAgIGZhc3RGcmVlKGltcCk7DQotLS0N Cj4gICAgICAgLy8gYWRqdXN0IHBvaW50ZXIgdG8gdGhlIGJlZ2lubmluZyBvZiB0aGUgcmF3IG1l bW9yeQ0KPiAgICAgICBzaXplX3QqIHJhd01lbSA9IHJlaW50ZXJwcmV0X2Nhc3Q8c2l6ZV90Kj4o aW1wKSAtIDE7DQo+ICAgICAgIGZhc3RGcmVlKHJhd01lbSk7DQo= 12947 2007-02-05 14:16:38 -0800 2007-02-09 22:46:12 -0800 a patch for preformance test Bug12535Patch.txt text/plain 3441 ian.eng.webkit SW5kZXg6IEphdmFTY3JpcHRDb3JlL2tqcy9jb2xsZWN0b3IuY3BwCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIEph dmFTY3JpcHRDb3JlL2tqcy9jb2xsZWN0b3IuY3BwCShyZXZpc2lvbiAxOTQwNykKKysrIEphdmFT Y3JpcHRDb3JlL2tqcy9jb2xsZWN0b3IuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC01NSw2ICs1NSw4 IEBACiAKICNkZWZpbmUgREVCVUdfQ09MTEVDVE9SIDAKIAorI2RlZmluZSBBTExPV19JTk5FUl9Q T0lOVEVSUyAxCisKIHVzaW5nIHN0ZDo6bWF4OwogCiBuYW1lc3BhY2UgS0pTIHsKQEAgLTE1OSw4 ICsxNjEsMTcgQEAgdm9pZCogQ29sbGVjdG9yOjphbGxvY2F0ZShzaXplX3QgcykKICAgICAgIGhl YXAubnVtT3ZlcnNpemVDZWxscyA9IG51bU92ZXJzaXplQ2VsbHM7CiAgICAgICBoZWFwLm92ZXJz aXplQ2VsbHMgPSBzdGF0aWNfY2FzdDxDb2xsZWN0b3JDZWxsICoqPihmYXN0UmVhbGxvYyhoZWFw Lm92ZXJzaXplQ2VsbHMsIG51bU92ZXJzaXplQ2VsbHMgKiBzaXplb2YoQ29sbGVjdG9yQ2VsbCAq KSkpOwogICAgIH0KLSAgICAKKworICAgIC8vIGFsbG9jYXRlIGV4dHJhIDggYnl0ZXMgYXQgdGhl IGJlZ2lubmluZywgdGhpcyBtYXkgbWFrZSB0aGUKKyAgICAvLyBvYmplY3Qgc3RhcnQgYWRkcmVz cyBub3QgYWxpZ25lZCB0byA4IGJ5dGVzLgorI2lmIEFMTE9XX0lOTkVSX1BPSU5URVJTCisgICAg c2l6ZV90KiByYXdNZW0gPSBzdGF0aWNfY2FzdDxzaXplX3QqPihmYXN0TWFsbG9jKHMgKyBzaXpl b2Yoc2l6ZV90KSkpOworICAgIC8vIHNob3VsZCB3ZSBjaGVjayBpZiBhbGxvY2F0aW9uIGZhaWxl ZD8/PworICAgICpyYXdNZW0gPSBzOworICAgIHZvaWQqIG5ld0NlbGwgPSByZWludGVycHJldF9j YXN0PHZvaWQqPihyYXdNZW0gKyAxKTsKKyNlbHNlCiAgICAgdm9pZCAqbmV3Q2VsbCA9IGZhc3RN YWxsb2Mocyk7CisjZW5kaWYKICAgICBoZWFwLm92ZXJzaXplQ2VsbHNbdXNlZE92ZXJzaXplQ2Vs bHNdID0gc3RhdGljX2Nhc3Q8Q29sbGVjdG9yQ2VsbCAqPihuZXdDZWxsKTsKICAgICBoZWFwLnVz ZWRPdmVyc2l6ZUNlbGxzID0gdXNlZE92ZXJzaXplQ2VsbHMgKyAxOwogICAgIGhlYXAubnVtTGl2 ZU9iamVjdHMgPSBudW1MaXZlT2JqZWN0cyArIDE7CkBAIC0yOTgsMTkgKzMwOSw0NyBAQCB2b2lk IENvbGxlY3Rvcjo6bWFya1N0YWNrT2JqZWN0c0NvbnNlcnZhCiAgIHNpemVfdCB1c2VkT3ZlcnNp emVDZWxscyA9IGhlYXAudXNlZE92ZXJzaXplQ2VsbHM7CiAgIENvbGxlY3RvckNlbGwgKipvdmVy c2l6ZUNlbGxzID0gaGVhcC5vdmVyc2l6ZUNlbGxzOwogCi0gIGNvbnN0IHNpemVfdCBsYXN0Q2Vs bE9mZnNldCA9IHNpemVvZihDb2xsZWN0b3JDZWxsKSAqIChDRUxMU19QRVJfQkxPQ0sgLSAxKTsK KyAgY29uc3Qgc2l6ZV90IGNlbGxTaXplID0gc2l6ZW9mKENvbGxlY3RvckNlbGwpOworICBjb25z dCBzaXplX3QgbGFzdENlbGxPZmZzZXQgPSBjZWxsU2l6ZSAqIChDRUxMU19QRVJfQkxPQ0sgLSAx KTsKIAogICB3aGlsZSAocCAhPSBlKSB7CiAgICAgY2hhciAqeCA9ICpwKys7CisjaWYgQUxMT1df SU5ORVJfUE9JTlRFUlMKKyAgICAvLyBCZWNhdXNlICd4JyBtYXkgcG9pbnQgdG8gdGhlIGJvZHkg b2YgYSBKUyBvYmplY3QsIGFsaWdubWVudCBkb2VzIG5vdAorICAgIC8vIGFwcGx5IHRvIGl0Lgor ICAgIGlmICh4KSB7CisjZWxzZQogICAgIGlmIChJU19DRUxMX0FMSUdORUQoeCkgJiYgeCkgewor I2VuZGlmCiAgICAgICBmb3IgKHNpemVfdCBibG9jayA9IDA7IGJsb2NrIDwgdXNlZEJsb2Nrczsg YmxvY2srKykgewotICAgICAgICBzaXplX3Qgb2Zmc2V0ID0geCAtIHJlaW50ZXJwcmV0X2Nhc3Q8 Y2hhciAqPihibG9ja3NbYmxvY2tdKTsKKyAgICAgICAgY2hhciogYmxvY2tTdGFydCA9IHJlaW50 ZXJwcmV0X2Nhc3Q8Y2hhcio+KGJsb2Nrc1tibG9ja10pOworICAgICAgICBzaXplX3Qgb2Zmc2V0 ID0geCAtIGJsb2NrU3RhcnQ7CisjaWYgQUxMT1dfSU5ORVJfUE9JTlRFUlMKKyAgICAgICAgaWYg KG9mZnNldCA8PSBsYXN0Q2VsbE9mZnNldCkgeworICAgICAgICAgIHggPSBibG9ja1N0YXJ0ICsg KG9mZnNldCAvIGNlbGxTaXplKSAqIGNlbGxTaXplOworICAgICAgICAgIGdvdG8gZ290R29vZFBv aW50ZXI7CisgICAgICAgIH0KKyNlbHNlCiAgICAgICAgIGlmIChvZmZzZXQgPD0gbGFzdENlbGxP ZmZzZXQgJiYgb2Zmc2V0ICUgc2l6ZW9mKENvbGxlY3RvckNlbGwpID09IDApCiAgICAgICAgICAg Z290byBnb3RHb29kUG9pbnRlcjsKKyNlbmRpZgogICAgICAgfQogICAgICAgZm9yIChzaXplX3Qg aSA9IDA7IGkgIT0gdXNlZE92ZXJzaXplQ2VsbHM7IGkrKykKLSAgICAgICAgaWYgKHggPT0gcmVp bnRlcnByZXRfY2FzdDxjaGFyICo+KG92ZXJzaXplQ2VsbHNbaV0pKQotICAgICAgICAgIGdvdG8g Z290R29vZFBvaW50ZXI7CisgICAgICAgIGlmICh4ID09IHJlaW50ZXJwcmV0X2Nhc3Q8Y2hhciAq PihvdmVyc2l6ZUNlbGxzW2ldKSkgeworICAgICAgICAgIGNoYXIqIGNlbGxTdGFydCA9IHJlaW50 ZXJwcmV0X2Nhc3Q8Y2hhcio+KG92ZXJzaXplQ2VsbHNbaV0pOworI2lmIEFMTE9XX0lOTkVSX1BP SU5URVJTCisgICAgICAgICAgaWYgKGNlbGxTdGFydCA8PSB4KSB7CisgICAgICAgICAgICBzaXpl X3QgbGVuZ3RoID0gKihyZWludGVycHJldF9jYXN0PHNpemVfdCo+KGNlbGxTdGFydCkgLSAxKTsK KyAgICAgICAgICAgIGlmICh4IDwgY2VsbFN0YXJ0ICsgbGVuZ3RoKSB7CisgICAgICAgICAgICAg IHggPSBjZWxsU3RhcnQ7CisgICAgICAgICAgICAgIGdvdG8gZ290R29vZFBvaW50ZXI7CisgICAg ICAgICAgICB9CisgICAgICAgICAgfQorI2Vsc2UKKyAgICAgICAgICBpZiAoY2VsbFN0YXJ0ID09 IHgpCisgICAgICAgICAgICBnb3RvIGdvdEdvb2RQb2ludGVyOworI2VuZGlmCisgICAgICAgIH0K ICAgICAgIGNvbnRpbnVlOwogCiBnb3RHb29kUG9pbnRlcjoKQEAgLTYwNCw4ICs2NDMsMTMgQEAg Ym9vbCBDb2xsZWN0b3I6OmNvbGxlY3QoKQogI2lmIERFQlVHX0NPTExFQ1RPUgogICAgICAgaGVh cC5vdmVyc2l6ZUNlbGxzW2NlbGxdLT51LmZyZWVDZWxsLnplcm9JZkZyZWUgPSAwOwogI2Vsc2UK KyNpZiBBTExPV19JTk5FUl9QT0lOVEVSUworICAgICAgc2l6ZV90KiByYXdNZW0gPSByZWludGVy cHJldF9jYXN0PHNpemVfdCo+KGltcCkgLSAxOworICAgICAgZmFzdEZyZWUocmF3TWVtKTsKKyNl bHNlCiAgICAgICBmYXN0RnJlZShpbXApOwogI2VuZGlmCisjZW5kaWYKIAogICAgICAgLy8gc3dh cCB3aXRoIHRoZSBsYXN0IG92ZXJzaXplIGNlbGwgc28gd2UgY29tcGFjdCBhcyB3ZSBnbwogICAg ICAgaGVhcC5vdmVyc2l6ZUNlbGxzW2NlbGxdID0gaGVhcC5vdmVyc2l6ZUNlbGxzW2hlYXAudXNl ZE92ZXJzaXplQ2VsbHMgLSAxXTsK 13507 2007-03-06 22:38:40 -0800 2007-03-07 00:36:31 -0800 Proposing fix 12535_patch.txt text/plain 1410 huanr SW5kZXg6IEphdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2NyaXB0 Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDIwMDA2KQorKysgSmF2YVNjcmlwdENvcmUvQ2hhbmdl TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMTMgQEAKKzIwMDctMDMtMDYgIEFucm9uZyBI dSAgPGh1YW5yQHlhaG9vLmNvbT4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMh KS4KKworCUJ1ZyAxMjUzNTogU3RhY2stb3B0aW1pemluZyBjb21waWxlcnMgY2FuIHRyaWNrIEdD IGludG8gZnJlZWluZyBpbi11c2Ugb2JqZWN0cworCUZpeDogVXNlIGFsbG9jYSBhbmQgZXhwbGlj aXRseSBwdXQgdGhlIG9iamVjdCByZWZlcmVuY2Ugb250byB0aGUgc3RhY2suCisKKyAgICAgICAg KiBranMvaW50ZXJuYWwuY3BwOgorICAgICAgICAoS0pTOjpTdHJpbmdJbXA6OnRvT2JqZWN0KToK KwogMjAwNy0wMy0wNiAgR2VvZmZyZXkgR2FyZW4gIDxnZ2FyZW5AYXBwbGUuY29tPgogCiAgICAg ICAgIFJldmlld2VkIGJ5IE1hY2llaiBTdGFjaG93aWFrLgpJbmRleDogSmF2YVNjcmlwdENvcmUv a2pzL2ludGVybmFsLmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2NyaXB0Q29yZS9ranMvaW50ZXJu YWwuY3BwCShyZXZpc2lvbiAxOTk5MikKKysrIEphdmFTY3JpcHRDb3JlL2tqcy9pbnRlcm5hbC5j cHAJKHdvcmtpbmcgY29weSkKQEAgLTQ3LDYgKzQ3LDcgQEAKICNpbmNsdWRlIDx3dGYvVmVjdG9y Lmg+CiAjaW5jbHVkZSA8bWF0aC5oPgogI2luY2x1ZGUgPHN0ZGlvLmg+CisjaW5jbHVkZSA8bWFs bG9jLmg+CiAKIG5hbWVzcGFjZSBLSlMgewogCkBAIC03OCw2ICs3OSwxMiBAQCBVU3RyaW5nIFN0 cmluZ0ltcDo6dG9TdHJpbmcoRXhlY1N0YXRlICopCiAKIEpTT2JqZWN0ICpTdHJpbmdJbXA6OnRv T2JqZWN0KEV4ZWNTdGF0ZSAqZXhlYykgY29uc3QKIHsKKyAgICAvLyBQdXQgdGhlIHJlZmVyZW5j ZSB0byB0aGlzIG9uIHRoZSBzdGFjayBzbyBpdCBpcyBub3Qgc3ViamVjdCB0byBnYXJiYWdlCisg ICAgLy8gY29sbGVjdGlvbi4KKyAgICAvLyBTZWUgd2Via2l0IGJ1ZyAxMjUzNS4KKyAgICBTdHJp bmdJbXAgKipwdHIgPSBzdGF0aWNfY2FzdDxTdHJpbmdJbXAgKio+KF9hbGxvY2Eoc2l6ZW9mKFN0 cmluZ0ltcCAqKikpKTsKKyAgICAqcHRyID0gY29uc3RfY2FzdDxTdHJpbmdJbXAgKj4odGhpcyk7 CisKICAgICByZXR1cm4gbmV3IFN0cmluZ0luc3RhbmNlKGV4ZWMtPmxleGljYWxJbnRlcnByZXRl cigpLT5idWlsdGluU3RyaW5nUHJvdG90eXBlKCksIHZhbCk7CiB9CiAK 13519 2007-03-07 11:33:41 -0800 2007-03-07 11:36:52 -0800 Fix 12535_patch.txt text/plain 1353 huanr SW5kZXg6IEphdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2NyaXB0 Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDIwMDA2KQorKysgSmF2YVNjcmlwdENvcmUvQ2hhbmdl TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMTMgQEAKKzIwMDctMDMtMDYgIEFucm9uZyBI dSAgPGh1YW5yQHlhaG9vLmNvbT4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMh KS4KKworCUJ1ZyAxMjUzNTogU3RhY2stb3B0aW1pemluZyBjb21waWxlcnMgY2FuIHRyaWNrIEdD IGludG8gZnJlZWluZyBpbi11c2Ugb2JqZWN0cworCUZpeDogVXNlIGFsbG9jYSBhbmQgZXhwbGlj aXRseSBwdXQgdGhlIG9iamVjdCByZWZlcmVuY2Ugb250byB0aGUgc3RhY2suCisKKyAgICAgICAg KiBranMvaW50ZXJuYWwuY3BwOgorICAgICAgICAoS0pTOjpTdHJpbmdJbXA6OnRvT2JqZWN0KToK KwogMjAwNy0wMy0wNiAgR2VvZmZyZXkgR2FyZW4gIDxnZ2FyZW5AYXBwbGUuY29tPgogCiAgICAg ICAgIFJldmlld2VkIGJ5IE1hY2llaiBTdGFjaG93aWFrLgpJbmRleDogSmF2YVNjcmlwdENvcmUv a2pzL2ludGVybmFsLmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2NyaXB0Q29yZS9ranMvaW50ZXJu YWwuY3BwCShyZXZpc2lvbiAxOTk5MikKKysrIEphdmFTY3JpcHRDb3JlL2tqcy9pbnRlcm5hbC5j cHAJKHdvcmtpbmcgY29weSkKQEAgLTc4LDcgKzc4LDExIEBAIFVTdHJpbmcgU3RyaW5nSW1wOjp0 b1N0cmluZyhFeGVjU3RhdGUgKikKIAogSlNPYmplY3QgKlN0cmluZ0ltcDo6dG9PYmplY3QoRXhl Y1N0YXRlICpleGVjKSBjb25zdAogewotICAgIHJldHVybiBuZXcgU3RyaW5nSW5zdGFuY2UoZXhl Yy0+bGV4aWNhbEludGVycHJldGVyKCktPmJ1aWx0aW5TdHJpbmdQcm90b3R5cGUoKSwgdmFsKTsK KyAgICAvLyBQdXQgdGhlIHJlZmVyZW5jZSBvbnRvIHRoZSBzdGFjayBzbyBpdCBpcyBub3Qgc3Vi amVjdCB0byBnYXJiYWdlIGNvbGxlY3Rpb24uCisgICAgLy8gU2VlIHdlYmtpdCBidWcgMTI1MzUu CisgICAgVVN0cmluZyB2YWxDb3B5ID0gdmFsOworCisgICAgcmV0dXJuIG5ldyBTdHJpbmdJbnN0 YW5jZShleGVjLT5sZXhpY2FsSW50ZXJwcmV0ZXIoKS0+YnVpbHRpblN0cmluZ1Byb3RvdHlwZSgp LCB2YWxDb3B5KTsKIH0KIAogLy8gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIE51bWJl ckltcCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K