39893 2010-05-28 11:59:24 -0700 Explicitly use PTHREAD_MUTEX_NORMAL to create pthread mutex 2010-06-01 12:53:44 -0700 1 1 1 Unclassified WebKit Web Template Framework 528+ (Nightly build) All Other RESOLVED FIXED P2 Normal --- 1 yong.li.webkit webkit-unassigned ap commit-queue darin eric sam staikos xan.lopez oldest_to_newest 231855 0 yong.li.webkit 2010-05-28 11:59:24 -0700 There're some places in webkit that assumes mutex cannot be recursive like this: ASSERT(!mutex.tryLock()); However, PTHREAD_MUTEX_DEFAULT can be PTHREAD_MUTEX_RECURSIVE depending the implementation. Let's explicitly make sure we're creating non-recursive mutex. 231857 1 57359 yong.li.webkit 2010-05-28 12:05:21 -0700 Created attachment 57359 the patch 231859 2 eric 2010-05-28 12:12:30 -0700 Attachment 57359 did not build on mac: Build output: http://webkit-commit-queue.appspot.com/results/2597047 231864 3 yong.li.webkit 2010-05-28 12:18:19 -0700 (In reply to comment #2) > Attachment 57359 [details] did not build on mac: > Build output: http://webkit-commit-queue.appspot.com/results/2597047 weird. struct T t = { 0 }; is a typical way to zero the struct 231944 4 ap 2010-05-28 14:32:55 -0700 The assertion checks that the mutex is not used recursively, it doesn't check how it's implemented. 231957 5 yong.li.webkit 2010-05-28 14:50:17 -0700 (In reply to comment #4) > The assertion checks that the mutex is not used recursively, it doesn't check how it's implemented. If the mutex is recursive (PTHREAD_MUTEX_RECURSIVE), the assertion will fail. 231961 6 ap 2010-05-28 14:53:55 -0700 Oh sorry, you're of course right. 231973 7 yong.li.webkit 2010-05-28 15:33:41 -0700 The other solution is: 1) add a flag in Mutex: #ifndef NDEBUG bool isLocked() const { return m_isLocked; } bool m_isLocked; #endif 2) set it in lock() and unlock() 3) change assertions to ASSERT(mutex.isLocked()) 232121 8 57359 sam 2010-05-29 10:06:55 -0700 Comment on attachment 57359 the patch r- as this breaks the mac build. 232122 9 sam 2010-05-29 10:15:49 -0700 Can we do this as a compile time check. #if PTHREAD_MUTEX_DEFAULT == PTHREAD_MUTEX_NORMAL ...old code #else ...your code #endif I believe this is breaking the mac since the darwin implementation of pthread_t has a nested struct or array so you would have to initialize it with something like pt = {0, {0}}; I don't think depending on the implementations representation of pthread_t is a good idea though. 232156 10 yong.li.webkit 2010-05-29 17:23:29 -0700 (In reply to comment #9) > Can we do this as a compile time check. > > #if PTHREAD_MUTEX_DEFAULT == PTHREAD_MUTEX_NORMAL > ...old code > #else > ...your code > #endif I thought about this, but it also assumes PTHREAD_MUTEX_NORMAL must be a constant. If PTHREAD_MUTEX_NORMAL is implemented by a function, this cannot build. Probably we can ignore this case? > > I believe this is breaking the mac since the darwin implementation of pthread_t has a nested struct or array so you would have to initialize it with something like pt = {0, {0}}; I don't think depending on the implementations representation of pthread_t is a good idea though. I can remove the initializer, because static variables are always zeroed. 232157 11 57417 yong.li.webkit 2010-05-29 17:34:04 -0700 Created attachment 57417 Updated 232165 12 57417 darin 2010-05-29 21:01:14 -0700 Comment on attachment 57417 Updated Patch looks generally good, but I have some concerns. > + // Make sure it's not the same value as PTHREAD_MUTEX_INITIALIZER. This comment makes no sense. Why is it important to make sure that something is not the same value as PTHREAD_MUTEX_INITIALIZER? How is that relevant at all? > + // Static variables are always zeroed. > + static pthread_mutex_t s_zeroedMutex; > + m_mutex = s_zeroedMutex; It seems really strange to do it that way. If you just want to zero something out, the best way I can think of is: memset(&m_mutex, 0, sizeof(m_mutex)); No need for a global variable. But why does m_mutex need to be initialized twice? Doesn't pthread_mutex_init do a complete job? Why the need to initialize it before calling that? review- because I don't think we should land this with the extra unneeded code and the mysterious comment 232357 13 yong.li.webkit 2010-05-31 07:14:00 -0700 (In reply to comment #12) > (From update of attachment 57417 [details]) > Patch looks generally good, but I have some concerns. > > + // Make sure it's not the same value as PTHREAD_MUTEX_INITIALIZER. > This comment makes no sense. Why is it important to make sure that something is not the same value as PTHREAD_MUTEX_INITIALIZER? How is that relevant at all? pthread_mutex_init and pthread_mutex_destroy are not supposed to be called on PTHREAD_MUTEX_INITIALIZER. I cannot find any scription that defines the behavior. So I assume the behavior is undefined, and up to implementation. > > + // Static variables are always zeroed. > > + static pthread_mutex_t s_zeroedMutex; > > + m_mutex = s_zeroedMutex; > It seems really strange to do it that way. If you just want to zero something out, the best way I can think of is: > memset(&m_mutex, 0, sizeof(m_mutex)); > No need for a global variable. I can change it to memset 232362 14 57462 yong.li.webkit 2010-05-31 07:36:15 -0700 Created attachment 57462 use memset 232431 15 darin 2010-05-31 09:56:49 -0700 (In reply to comment #13) > (In reply to comment #12) > > > + // Make sure it's not the same value as PTHREAD_MUTEX_INITIALIZER. > > This comment makes no sense. Why is it important to make sure that something is not the same value as PTHREAD_MUTEX_INITIALIZER? How is that relevant at all? > > pthread_mutex_init and pthread_mutex_destroy are not supposed to be called on PTHREAD_MUTEX_INITIALIZER. I cannot find any scription that defines the behavior. So I assume the behavior is undefined, and up to implementation. I think you're misunderstanding this. I read over the various documentation, and yes, it's true that you should not use both PTHREAD_MUTEXT_INITIALIZER and pthread_mutex_init on the same mutex, but that does not mean that you have to pre-initialize the mutex before calling pthread_mutex_init. It just means that it's a programming mistake to both use PTHREAD_MUTEXT_INITIALIZER and pthread_mutex_init. 232435 16 57462 darin 2010-05-31 10:01:25 -0700 Comment on attachment 57462 use memset > + // Make sure it's not the same value as PTHREAD_MUTEX_INITIALIZER. > + memset(&m_mutex, 0, sizeof(pthread_mutex_t)); If we are doing this memset, I think it's better style to call sizeof(m_mutex) here instead of sizeof(pthread_mutex_t), because that way you can see looking at this line of code that it's correct without having to look up the type of m_mutex to double check that it's a pthread_mutex_t. As I said in my previous comment in this bug, this comment and code are not needed, and I am almost certain the comment reflects a misunderstanding on your part. I don't want to confuse future programmers working on this code. Initializing to zero does have a small good effect. It gives us more predictable behavior if pthread_mutex_init fails. Both the old code path and the new code path have the same failing in that they don't check the error return of pthread_mutex_init. But this issue is not specific to this new code path and applies just as much to the PTHREAD_MUTEX_NORMAL == PTHREAD_MUTEX_DEFAULT case. Despite the fact that this patch is otherwise just fine, I'm going to say review- because I don't want to check in a mysterious comment or unneeded code. The only difference between the two branches of the #if should be the attributes passed in to pthread_mutex_init. 232501 17 yong.li.webkit 2010-05-31 12:59:33 -0700 (In reply to comment #15) > (In reply to comment #13) > > (In reply to comment #12) > > > > + // Make sure it's not the same value as PTHREAD_MUTEX_INITIALIZER. > > > This comment makes no sense. Why is it important to make sure that something is not the same value as PTHREAD_MUTEX_INITIALIZER? How is that relevant at all? > > > > pthread_mutex_init and pthread_mutex_destroy are not supposed to be called on PTHREAD_MUTEX_INITIALIZER. I cannot find any scription that defines the behavior. So I assume the behavior is undefined, and up to implementation. > > I think you're misunderstanding this. I read over the various documentation, and yes, it's true that you should not use both PTHREAD_MUTEXT_INITIALIZER and pthread_mutex_init on the same mutex, but that does not mean that you have to pre-initialize the mutex before calling pthread_mutex_init. It just means that it's a programming mistake to both use PTHREAD_MUTEXT_INITIALIZER and pthread_mutex_init. If we don't initialize the mutex, what if the mutex just happens to be the same value as PTHREAD_MUTEXT_INITIALIZER? Although the chance if very small. OK, I'll remove that code anyway. 232502 18 57492 yong.li.webkit 2010-05-31 13:03:17 -0700 Created attachment 57492 updated 232556 19 darin 2010-05-31 18:18:30 -0700 (In reply to comment #17) > If we don't initialize the mutex, what if the mutex just happens to be the same value as PTHREAD_MUTEXT_INITIALIZER? Although the chance if very small. Not important to this patch any more, but that question shows a misunderstanding. There's no way you could set the mutex to a value and guarantee it's not the same as PTHREAD_MUTEX_INITIALIZER, nor would you want to. I think you're just reading too much into some documentation you read. pthread_mutex_init does not require that before you call it you set the mutex up with a bit pattern that happens to not be equal to PTHREAD_MUTEX_INITIALIZER. And if it did require that I'm not sure how you would accomplish that portably anyway. There are two ways to initialize a pthreads mutex. One is to call pthread_mutex_init and the other is to use PTHREAD_MUTEX_INITIALIZER. In our case we are using pthread_mutex_init. 232775 20 yong.li.webkit 2010-06-01 08:56:59 -0700 (In reply to comment #19) > (In reply to comment #17) > > If we don't initialize the mutex, what if the mutex just happens to be the same value as PTHREAD_MUTEXT_INITIALIZER? Although the chance if very small. > > Not important to this patch any more, but that question shows a misunderstanding. There's no way you could set the mutex to a value and guarantee it's not the same as PTHREAD_MUTEX_INITIALIZER, nor would you want to. I think you're just reading too much into some documentation you read. pthread_mutex_init does not require that before you call it you set the mutex up with a bit pattern that happens to not be equal to PTHREAD_MUTEX_INITIALIZER. And if it did require that I'm not sure how you would accomplish that portably anyway. There are two ways to initialize a pthreads mutex. One is to call pthread_mutex_init and the other is to use PTHREAD_MUTEX_INITIALIZER. In our case we are using pthread_mutex_init. yeah. probably I have thought too much 232830 21 57492 commit-queue 2010-06-01 10:46:53 -0700 Comment on attachment 57492 updated Clearing flags on attachment: 57492 Committed r60487: <http://trac.webkit.org/changeset/60487> 232831 22 commit-queue 2010-06-01 10:47:03 -0700 All reviewed patches have been landed. Closing bug. 232873 23 xan.lopez 2010-06-01 11:36:13 -0700 This is not quite working on GTK+: ../../JavaScriptCore/wtf/ThreadingPthreads.cpp:238:5: warning: "PTHREAD_MUTEX_NORMAL" is not defined ../../JavaScriptCore/wtf/ThreadingPthreads.cpp:238:29: warning: "PTHREAD_MUTEX_DEFAULT" is not defined 232875 24 darin 2010-06-01 11:38:59 -0700 (In reply to comment #23) > This is not quite working on GTK+: > > ../../JavaScriptCore/wtf/ThreadingPthreads.cpp:238:5: warning: "PTHREAD_MUTEX_NORMAL" is not defined > ../../JavaScriptCore/wtf/ThreadingPthreads.cpp:238:29: warning: "PTHREAD_MUTEX_DEFAULT" is not defined I suggest doing this for now to fix the build: #if !defined PTHREAD_MUTEX_NORMAL || PTHREAD_MUTEX_NORMAL == PTHREAD_MUTEX_DEFAULT Later we can figure it out. 232916 25 yong.li.webkit 2010-06-01 12:53:44 -0700 (In reply to comment #23) > This is not quite working on GTK+: > ../../JavaScriptCore/wtf/ThreadingPthreads.cpp:238:5: warning: "PTHREAD_MUTEX_NORMAL" is not defined > ../../JavaScriptCore/wtf/ThreadingPthreads.cpp:238:29: warning: "PTHREAD_MUTEX_DEFAULT" is not defined Oops. sorry for this. but PTHREAD_MUTEX_NORMAL is supposed to be defined in pthread.h. Are you fixing it as Darin sugguests now? 57359 2010-05-28 12:05:21 -0700 2010-05-29 17:34:04 -0700 the patch 39893.patch text/plain 1406 yong.li.webkit ZGlmZiAtLWdpdCBhL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZyBiL0phdmFTY3JpcHRDb3JlL0No YW5nZUxvZwppbmRleCA5YWEzMTgwLi4zYmJhZTdlIDEwMDY0NAotLS0gYS9KYXZhU2NyaXB0Q29y ZS9DaGFuZ2VMb2cKKysrIGIvSmF2YVNjcmlwdENvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTMg QEAKKzIwMTAtMDUtMjggIFlvbmcgTGkgIDx5b2xpQHJpbS5jb20+CisKKyAgICAgICAgUmV2aWV3 ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgRXhwbGljaXRseSB1c2UgUFRIUkVBRF9N VVRFWF9OT1JNQUwgdG8gY3JlYXRlIHB0aHJlYWQgbXV0ZXguCisgICAgICAgIGh0dHBzOi8vYnVn cy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0zOTg5MworCisgICAgICAgICogd3RmL1RocmVh ZGluZ1B0aHJlYWRzLmNwcDoKKyAgICAgICAgKFdURjo6TXV0ZXg6Ok11dGV4KToKKwogMjAxMC0w NS0yNSAgR2VvZmZyZXkgR2FyZW4gIDxnZ2FyZW5AYXBwbGUuY29tPgogCiAgICAgICAgIEZpeGVk IGJ1aWxkIGZhaWx1cmUgY2F1c2VkIGJ5IG1lcmdlLgpkaWZmIC0tZ2l0IGEvSmF2YVNjcmlwdENv cmUvd3RmL1RocmVhZGluZ1B0aHJlYWRzLmNwcCBiL0phdmFTY3JpcHRDb3JlL3d0Zi9UaHJlYWRp bmdQdGhyZWFkcy5jcHAKaW5kZXggMzNkZTJkMi4uYjc3YzYwNyAxMDA2NDQKLS0tIGEvSmF2YVNj cmlwdENvcmUvd3RmL1RocmVhZGluZ1B0aHJlYWRzLmNwcAorKysgYi9KYXZhU2NyaXB0Q29yZS93 dGYvVGhyZWFkaW5nUHRocmVhZHMuY3BwCkBAIC0yNzEsNyArMjcxLDIyIEBAIFRocmVhZElkZW50 aWZpZXIgY3VycmVudFRocmVhZCgpCiAKIE11dGV4OjpNdXRleCgpCiB7Ci0gICAgcHRocmVhZF9t dXRleF9pbml0KCZtX211dGV4LCBOVUxMKTsKKyAgICAvLyBNYWtlIHN1cmUgaXQncyBub3QgdGhl IHNhbWUgdmFsdWUgYXMgUFRIUkVBRF9NVVRFWF9JTklUSUFMSVpFUi4KKyAgICBzdGF0aWMgcHRo cmVhZF9tdXRleF90IHNfemVyb2VkTXV0ZXggPSB7IDAgfTsKKyAgICBtX211dGV4ID0gc196ZXJv ZWRNdXRleDsKKworICAgIGlmIChQVEhSRUFEX01VVEVYX05PUk1BTCA9PSBQVEhSRUFEX01VVEVY X0RFRkFVTFQpIHsKKyAgICAgICAgcHRocmVhZF9tdXRleF9pbml0KCZtX211dGV4LCAwKTsKKyAg ICAgICAgcmV0dXJuOworICAgIH0KKworICAgIHB0aHJlYWRfbXV0ZXhhdHRyX3QgYXR0ciA9IHsg MCB9OworICAgIHB0aHJlYWRfbXV0ZXhhdHRyX2luaXQoJmF0dHIpOworICAgIHB0aHJlYWRfbXV0 ZXhhdHRyX3NldHR5cGUoJmF0dHIsIFBUSFJFQURfTVVURVhfTk9STUFMKTsKKworICAgIHB0aHJl YWRfbXV0ZXhfaW5pdCgmbV9tdXRleCwgJmF0dHIpOworCisgICAgcHRocmVhZF9tdXRleGF0dHJf ZGVzdHJveSgmYXR0cik7CiB9CiAKIE11dGV4Ojp+TXV0ZXgoKQo= 57417 2010-05-29 17:34:04 -0700 2010-05-31 07:40:25 -0700 Updated 39893.patch text/plain 1404 yong.li.webkit ZGlmZiAtLWdpdCBhL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZyBiL0phdmFTY3JpcHRDb3JlL0No YW5nZUxvZwppbmRleCA0Yjg5Y2ZkLi42ZWVmZTYyIDEwMDY0NAotLS0gYS9KYXZhU2NyaXB0Q29y ZS9DaGFuZ2VMb2cKKysrIGIvSmF2YVNjcmlwdENvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTMg QEAKKzIwMTAtMDUtMjggIFlvbmcgTGkgIDx5b2xpQHJpbS5jb20+CisKKyAgICAgICAgUmV2aWV3 ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgRXhwbGljaXRseSB1c2UgUFRIUkVBRF9N VVRFWF9OT1JNQUwgdG8gY3JlYXRlIHB0aHJlYWQgbXV0ZXguCisgICAgICAgIGh0dHBzOi8vYnVn cy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0zOTg5MworCisgICAgICAgICogd3RmL1RocmVh ZGluZ1B0aHJlYWRzLmNwcDoKKyAgICAgICAgKFdURjo6TXV0ZXg6Ok11dGV4KToKKwogMjAxMC0w NS0yMCAgRGFyaW4gQWRsZXIgIDxkYXJpbkBhcHBsZS5jb20+CiAKICAgICAgICAgUmV2aWV3ZWQg YnkgRXJpYyBTZWlkZWwuCmRpZmYgLS1naXQgYS9KYXZhU2NyaXB0Q29yZS93dGYvVGhyZWFkaW5n UHRocmVhZHMuY3BwIGIvSmF2YVNjcmlwdENvcmUvd3RmL1RocmVhZGluZ1B0aHJlYWRzLmNwcApp bmRleCBmNDY4Y2UyLi5lNTMxNWEyIDEwMDY0NAotLS0gYS9KYXZhU2NyaXB0Q29yZS93dGYvVGhy ZWFkaW5nUHRocmVhZHMuY3BwCisrKyBiL0phdmFTY3JpcHRDb3JlL3d0Zi9UaHJlYWRpbmdQdGhy ZWFkcy5jcHAKQEAgLTIzNSw3ICsyMzUsMjYgQEAgVGhyZWFkSWRlbnRpZmllciBjdXJyZW50VGhy ZWFkKCkKIAogTXV0ZXg6Ok11dGV4KCkKIHsKLSAgICBwdGhyZWFkX211dGV4X2luaXQoJm1fbXV0 ZXgsIE5VTEwpOworI2lmIFBUSFJFQURfTVVURVhfTk9STUFMID09IFBUSFJFQURfTVVURVhfREVG QVVMVAorCisgICAgcHRocmVhZF9tdXRleF9pbml0KCZtX211dGV4LCAwKTsKKworI2Vsc2UKKwor ICAgIC8vIE1ha2Ugc3VyZSBpdCdzIG5vdCB0aGUgc2FtZSB2YWx1ZSBhcyBQVEhSRUFEX01VVEVY X0lOSVRJQUxJWkVSLgorICAgIC8vIFN0YXRpYyB2YXJpYWJsZXMgYXJlIGFsd2F5cyB6ZXJvZWQu CisgICAgc3RhdGljIHB0aHJlYWRfbXV0ZXhfdCBzX3plcm9lZE11dGV4OworICAgIG1fbXV0ZXgg PSBzX3plcm9lZE11dGV4OworCisgICAgcHRocmVhZF9tdXRleGF0dHJfdCBhdHRyOworICAgIHB0 aHJlYWRfbXV0ZXhhdHRyX2luaXQoJmF0dHIpOworICAgIHB0aHJlYWRfbXV0ZXhhdHRyX3NldHR5 cGUoJmF0dHIsIFBUSFJFQURfTVVURVhfTk9STUFMKTsKKworICAgIHB0aHJlYWRfbXV0ZXhfaW5p dCgmbV9tdXRleCwgJmF0dHIpOworCisgICAgcHRocmVhZF9tdXRleGF0dHJfZGVzdHJveSgmYXR0 cik7CisKKyNlbmRpZgogfQogCiBNdXRleDo6fk11dGV4KCkK 57462 2010-05-31 07:36:15 -0700 2010-05-31 13:03:17 -0700 use memset 39893.patch text/plain 1517 yong.li.webkit ZGlmZiAtLWdpdCBhL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZyBiL0phdmFTY3JpcHRDb3JlL0No YW5nZUxvZwppbmRleCA3ZDI0YmU1Li42MjkzYTBmIDEwMDY0NAotLS0gYS9KYXZhU2NyaXB0Q29y ZS9DaGFuZ2VMb2cKKysrIGIvSmF2YVNjcmlwdENvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTMg QEAKKzIwMTAtMDUtMjggIFlvbmcgTGkgIDx5b2xpQHJpbS5jb20+CisKKyAgICAgICAgUmV2aWV3 ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgRXhwbGljaXRseSB1c2UgUFRIUkVBRF9N VVRFWF9OT1JNQUwgdG8gY3JlYXRlIHB0aHJlYWQgbXV0ZXguCisgICAgICAgIGh0dHBzOi8vYnVn cy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0zOTg5MworCisgICAgICAgICogd3RmL1RocmVh ZGluZ1B0aHJlYWRzLmNwcDoKKyAgICAgICAgKFdURjo6TXV0ZXg6Ok11dGV4KToKKwogMjAxMC0w NS0yMCAgR2VvZmZyZXkgR2FyZW4gIDxnZ2FyZW5AYXBwbGUuY29tPgogCiAgICAgICAgIFJldmll d2VkIGJ5IERhcmluIEFkbGVyLgpkaWZmIC0tZ2l0IGEvSmF2YVNjcmlwdENvcmUvd3RmL1RocmVh ZGluZ1B0aHJlYWRzLmNwcCBiL0phdmFTY3JpcHRDb3JlL3d0Zi9UaHJlYWRpbmdQdGhyZWFkcy5j cHAKaW5kZXggZjQ2OGNlMi4uNjVjMTk2YiAxMDA2NDQKLS0tIGEvSmF2YVNjcmlwdENvcmUvd3Rm L1RocmVhZGluZ1B0aHJlYWRzLmNwcAorKysgYi9KYXZhU2NyaXB0Q29yZS93dGYvVGhyZWFkaW5n UHRocmVhZHMuY3BwCkBAIC00MSw2ICs0MSw3IEBACiAjaW5jbHVkZSAiVGhyZWFkU3BlY2lmaWMu aCIKICNpbmNsdWRlICJVbnVzZWRQYXJhbS5oIgogI2luY2x1ZGUgPGVycm5vLmg+CisjaW5jbHVk ZSA8c3RyaW5nLmg+IC8vIEZvciBtZW1zZXQoKS4KIAogI2lmICFDT01QSUxFUihNU1ZDKQogI2lu Y2x1ZGUgPGxpbWl0cy5oPgpAQCAtMjM1LDcgKzIzNiwyNCBAQCBUaHJlYWRJZGVudGlmaWVyIGN1 cnJlbnRUaHJlYWQoKQogCiBNdXRleDo6TXV0ZXgoKQogewotICAgIHB0aHJlYWRfbXV0ZXhfaW5p dCgmbV9tdXRleCwgTlVMTCk7CisjaWYgUFRIUkVBRF9NVVRFWF9OT1JNQUwgPT0gUFRIUkVBRF9N VVRFWF9ERUZBVUxUCisKKyAgICBwdGhyZWFkX211dGV4X2luaXQoJm1fbXV0ZXgsIDApOworCisj ZWxzZQorCisgICAgLy8gTWFrZSBzdXJlIGl0J3Mgbm90IHRoZSBzYW1lIHZhbHVlIGFzIFBUSFJF QURfTVVURVhfSU5JVElBTElaRVIuCisgICAgbWVtc2V0KCZtX211dGV4LCAwLCBzaXplb2YocHRo cmVhZF9tdXRleF90KSk7CisKKyAgICBwdGhyZWFkX211dGV4YXR0cl90IGF0dHI7CisgICAgcHRo cmVhZF9tdXRleGF0dHJfaW5pdCgmYXR0cik7CisgICAgcHRocmVhZF9tdXRleGF0dHJfc2V0dHlw ZSgmYXR0ciwgUFRIUkVBRF9NVVRFWF9OT1JNQUwpOworCisgICAgcHRocmVhZF9tdXRleF9pbml0 KCZtX211dGV4LCAmYXR0cik7CisKKyAgICBwdGhyZWFkX211dGV4YXR0cl9kZXN0cm95KCZhdHRy KTsKKworI2VuZGlmCiB9CiAKIE11dGV4Ojp+TXV0ZXgoKQo= 57492 2010-05-31 13:03:17 -0700 2010-06-01 10:46:52 -0700 updated 39893.patch text/plain 1217 yong.li.webkit ZGlmZiAtLWdpdCBhL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZyBiL0phdmFTY3JpcHRDb3JlL0No YW5nZUxvZwppbmRleCA3ZDI0YmU1Li42MjkzYTBmIDEwMDY0NAotLS0gYS9KYXZhU2NyaXB0Q29y ZS9DaGFuZ2VMb2cKKysrIGIvSmF2YVNjcmlwdENvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTMg QEAKKzIwMTAtMDUtMjggIFlvbmcgTGkgIDx5b2xpQHJpbS5jb20+CisKKyAgICAgICAgUmV2aWV3 ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgRXhwbGljaXRseSB1c2UgUFRIUkVBRF9N VVRFWF9OT1JNQUwgdG8gY3JlYXRlIHB0aHJlYWQgbXV0ZXguCisgICAgICAgIGh0dHBzOi8vYnVn cy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0zOTg5MworCisgICAgICAgICogd3RmL1RocmVh ZGluZ1B0aHJlYWRzLmNwcDoKKyAgICAgICAgKFdURjo6TXV0ZXg6Ok11dGV4KToKKwogMjAxMC0w NS0yMCAgR2VvZmZyZXkgR2FyZW4gIDxnZ2FyZW5AYXBwbGUuY29tPgogCiAgICAgICAgIFJldmll d2VkIGJ5IERhcmluIEFkbGVyLgpkaWZmIC0tZ2l0IGEvSmF2YVNjcmlwdENvcmUvd3RmL1RocmVh ZGluZ1B0aHJlYWRzLmNwcCBiL0phdmFTY3JpcHRDb3JlL3d0Zi9UaHJlYWRpbmdQdGhyZWFkcy5j cHAKaW5kZXggZjQ2OGNlMi4uMDcwZTFjNiAxMDA2NDQKLS0tIGEvSmF2YVNjcmlwdENvcmUvd3Rm L1RocmVhZGluZ1B0aHJlYWRzLmNwcAorKysgYi9KYXZhU2NyaXB0Q29yZS93dGYvVGhyZWFkaW5n UHRocmVhZHMuY3BwCkBAIC0yMzUsNyArMjM1LDIxIEBAIFRocmVhZElkZW50aWZpZXIgY3VycmVu dFRocmVhZCgpCiAKIE11dGV4OjpNdXRleCgpCiB7Ci0gICAgcHRocmVhZF9tdXRleF9pbml0KCZt X211dGV4LCBOVUxMKTsKKyNpZiBQVEhSRUFEX01VVEVYX05PUk1BTCA9PSBQVEhSRUFEX01VVEVY X0RFRkFVTFQKKworICAgIHB0aHJlYWRfbXV0ZXhfaW5pdCgmbV9tdXRleCwgMCk7CisKKyNlbHNl CisKKyAgICBwdGhyZWFkX211dGV4YXR0cl90IGF0dHI7CisgICAgcHRocmVhZF9tdXRleGF0dHJf aW5pdCgmYXR0cik7CisgICAgcHRocmVhZF9tdXRleGF0dHJfc2V0dHlwZSgmYXR0ciwgUFRIUkVB RF9NVVRFWF9OT1JNQUwpOworCisgICAgcHRocmVhZF9tdXRleF9pbml0KCZtX211dGV4LCAmYXR0 cik7CisKKyAgICBwdGhyZWFkX211dGV4YXR0cl9kZXN0cm95KCZhdHRyKTsKKworI2VuZGlmCiB9 CiAKIE11dGV4Ojp+TXV0ZXgoKQo=