29729 2009-09-24 18:14:37 -0700 SQLiteTransaction should use BEGIN DEFERRED instead of BEGIN to begin read-only transactions 2009-11-11 21:43:31 -0800 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) All All RESOLVED WONTFIX P2 Normal --- 1 dumi dumi andersca aroben beidson commit-queue dglazkov fishd jorlow michaeln mjs mrowe sam oldest_to_newest 149911 0 dumi 2009-09-24 18:14:37 -0700 If a port builds its own sqlite lib and uses flags to turn BEGIN into BEGIN IMMEDIATE by default (like chromium), then scheduling multiple read-only transactions on the DB on the same DB thread will result in a deadlock. The DB thread will essentially be stuck on a task that tries to acquire a RESERVED lock on the DB file, while that lock is held by another task that waits in the queue. In order to prevent this, we should change SQLiteTransaction to explicitly issue a BEGIN DEFERRED command for read-only transactions. This change will also make sure that read-only transactions don't unnecessarily acquire a higher level lock that would delay other potential transactions on the same DB. 149918 1 mrowe 2009-09-24 19:02:44 -0700 Which flag is SQLite being built with to cause this change in behavior? Why is Chromium building SQLite in this non-standard manner? 149927 2 40098 dumi 2009-09-24 20:27:55 -0700 Created attachment 40098 patch 150140 3 michaeln 2009-09-25 13:58:09 -0700 Being explicit in webcore code about the type of transaction is a good thing regardless of how the underlying sqlite library is built. typo in the ChangeLog, DIFERRED s/b DEFERRED, otherwise lgtm (fwiw) @mark, to avoid the possibility of starting a transaction that ultimately fails for extraneous reasons, this suited Chrome's internal use of sqlite. 150146 4 40098 eric 2009-09-25 14:17:29 -0700 Comment on attachment 40098 patch I think it's fine to be explicit, assuming that "BEGIN" normally means "BEGIN DEFERRED". You need to answer Mark's question before we can commit this though. Also the ordering of the comments seems a bit odd. Maybe the two comments should just be unified into one to explain both cases? The links seem useful for explaining both. r+ but please consider the comment modifications, and make sure to answer Mark's query before any commit. 150147 5 mrowe 2009-09-25 14:17:52 -0700 (In reply to comment #3) > Being explicit in webcore code about the type of transaction is a good thing > regardless of how the underlying sqlite library is built. As far as I can tell SQLite has no compilation option that alters the behavior of the "BEGIN" statement, and "BEGIN" is explicitly documented as being equivalent to "BEGIN DEFERRED". > @mark, to avoid the possibility of starting a transaction that ultimately fails > for extraneous reasons, this suited Chrome's internal use of sqlite. It sounds like the fix is for Chrome to be explicit about the type of transaction it uses rather than patching SQLite. 150149 6 mrowe 2009-09-25 14:21:34 -0700 We're relying on SQLite to behave as documented. I don't believe that WebKit should change to support patched versions of SQLite that no longer match the documented behavior. 150152 7 michaeln 2009-09-25 14:28:04 -0700 @mark, well if you really want to force the chrome-team to jump thru some hoops... I still think being explicit about the nature of the transaction started by webcore's SQLiteTransaction class can only be considered a good thing. What's the downside? 150160 8 mrowe 2009-09-25 14:40:23 -0700 Using SQLite patched in this way is a problem because we can no longer rely on the documentation when writing new code that uses SQLite. Changing this instance to "BEGIN DEFERRED" may work around the current problem, but as new code is written and *correctly* uses only "BEGIN" it will be subtly incorrect in your configuration. The solution there is not to insist that we always use "BEGIN DEFERRED" but to not change the behavior of SQLite in the first place. 150168 9 michaeln 2009-09-25 14:59:27 -0700 (In reply to comment #8) > Using SQLite patched in this way is a problem because we can no longer rely on > the documentation when writing new code that uses SQLite. Changing this > instance to "BEGIN DEFERRED" may work around the current problem, but as new > code is written and *correctly* uses only "BEGIN" it will be subtly incorrect > in your configuration. The solution there is not to insist that we always use > "BEGIN DEFERRED" but to not change the behavior of SQLite in the first place. Maybe the chrome team should re-visit its decision to apply the publicly available patch to sqlite that has been applied. I'll mention this to brett. But that chrome change seems a bit out-of-scope for this particular code change. BEGIN == BEGIN DEFERRED by default, so I still don't see any downside in the context of this narrowly constrained code change. 150779 10 dumi 2009-09-28 18:51:58 -0700 Mark, I talked to dglazkov about this, and he brought up a good point. Every time we execute a SQL statement, SQLite implicitly creates a transaction. So even if we wanted to change all Chromium code that uses SQLite, but doesn't do it through WebCore, it wouldn't be as easy as grepping for BEGIN and changing all occurrences to BEGIN IMMEDIATE. We'd have to: 1. Find every SQL statement that we execute. 2. Figure out if it goes through WebCore or not. 3. If it doesn't, wrap each statement into a "BEGIN IMMEDIATE; " + sqlStatement + "COMMIT;" (or similar) construct. Even if this might seem like the right solution, going through the entire Chromium code base looking for SQL statements, and then wrapping each one of them into an explicit transaction seems unreasonable to us at this point. Another point I want to bring up is that EVERY WebKit port that changes the default behavior of SQLite's BEGIN command will suffer from this problem. Chromium might be the only port that does it at the moment, but it's not unthinkable that another port might want to do the same thing in the future. Without this patch, they'll run into unexpected, hard-to-debug deadlocks as soon as they change their default BEGIN behavior. We (Michael and I) feel that a 1-word change to WebKit that explicitly states the expected default behavior is a much smaller price to pay, even if this change seems redundant and unnecessary (although we think that explicitly (re-)stating our expectations is not redundant and has value). Any chance we could come to an agreement here? This is not just a nice-to-have or we-like-it-more-this-way change. Without this patch Chromium will not be able to support HTML5 DBs (unless we wrap all our current SQL statements into explicit transactions, which is probably not very likely to happen ever). 150978 11 40098 dglazkov 2009-09-29 11:41:55 -0700 Comment on attachment 40098 patch > + Starting all read-only transactions with an explicit BEGIN > + DIFERRED command instead of BEGIN, since some ports (chromium) DEFERRED -- typo. Otherwise, I think this is fine. I don't want to stir up a controversy here, but Dumi's arguments are pretty solid. 150985 12 40315 dumi 2009-09-29 11:56:56 -0700 Created attachment 40315 patch Fixed the typo and rearranged the comments in SQLiteTransaction a bit. 151008 13 40315 dglazkov 2009-09-29 12:51:35 -0700 Comment on attachment 40315 patch r=me. 151012 14 40315 commit-queue 2009-09-29 13:05:19 -0700 Comment on attachment 40315 patch Clearing flags on attachment: 40315 Committed r48894: <http://trac.webkit.org/changeset/48894> 151013 15 commit-queue 2009-09-29 13:05:23 -0700 All reviewed patches have been landed. Closing bug. 151014 16 sam 2009-09-29 13:07:08 -0700 Why was this landed. It doesn't seem like there was a consensus reached. 151016 17 dglazkov 2009-09-29 13:14:08 -0700 I didn't think there was much left to discuss? Mark raised a valid point, Dumi addressed it pretty thoroughly. The patch doesn't seem very controversial -- doesn't change behavior, fixes a fairly pressing issue. Did I do the wrong thing? 151020 18 sam 2009-09-29 13:23:16 -0700 (In reply to comment #17) > I didn't think there was much left to discuss? Mark raised a valid point, Dumi > addressed it pretty thoroughly. The patch doesn't seem very controversial -- > doesn't change behavior, fixes a fairly pressing issue. Did I do the wrong > thing? The last substantial comment ended with "Any chance we could come to an agreement here?", so yes, I think you acted prematurely here. I also don't see how Dumi addressed Marks comment. It seems the only issue here is that Chromium does not want to change on their end to match standard usage of SQLite. 151022 19 jorlow 2009-09-29 13:28:33 -0700 (In reply to comment #18) > (In reply to comment #17) > > I didn't think there was much left to discuss? Mark raised a valid point, Dumi > > addressed it pretty thoroughly. The patch doesn't seem very controversial -- > > doesn't change behavior, fixes a fairly pressing issue. Did I do the wrong > > thing? > > The last substantial comment ended with "Any chance we could come to an > agreement here?", so yes, I think you acted prematurely here. I also don't see > how Dumi addressed Marks comment. It seems the only issue here is that > Chromium does not want to change on their end to match standard usage of > SQLite. What is the downside to Apple and/or any of the other ports? The down side to Chromium changing how they do things is a substantial amount of changed code. I'd even go so far as to predict a performance hit and some bloat in executable size due to a lot of extra SQL code being added. If we tried to upstream a build option to SQLite to change the semantics, would that make everyone happy? Based on Mark's reasoning in the beginning of the thread, it sounds like it would. 151029 20 dglazkov 2009-09-29 13:43:04 -0700 Rolled out as http://trac.webkit.org/changeset/48897. 151031 21 sam 2009-09-29 13:44:23 -0700 (In reply to comment #19) > (In reply to comment #18) > > (In reply to comment #17) > > > I didn't think there was much left to discuss? Mark raised a valid point, Dumi > > > addressed it pretty thoroughly. The patch doesn't seem very controversial -- > > > doesn't change behavior, fixes a fairly pressing issue. Did I do the wrong > > > thing? > > > > The last substantial comment ended with "Any chance we could come to an > > agreement here?", so yes, I think you acted prematurely here. I also don't see > > how Dumi addressed Marks comment. It seems the only issue here is that > > Chromium does not want to change on their end to match standard usage of > > SQLite. > > What is the downside to Apple and/or any of the other ports? > I think Marks objections are outlined well in comment #8. 151035 22 jorlow 2009-09-29 13:59:08 -0700 (In reply to comment #21) > (In reply to comment #19) > > (In reply to comment #18) > > > (In reply to comment #17) > > > > I didn't think there was much left to discuss? Mark raised a valid point, Dumi > > > > addressed it pretty thoroughly. The patch doesn't seem very controversial -- > > > > doesn't change behavior, fixes a fairly pressing issue. Did I do the wrong > > > > thing? > > > > > > The last substantial comment ended with "Any chance we could come to an > > > agreement here?", so yes, I think you acted prematurely here. I also don't see > > > how Dumi addressed Marks comment. It seems the only issue here is that > > > Chromium does not want to change on their end to match standard usage of > > > SQLite. > > > > What is the downside to Apple and/or any of the other ports? > > > > I think Marks objections are outlined well in comment #8. All of his objections only apply to the Chromium port. We agree that they are valid concerns, but the Chromium port would rather assume the risk Mark outline in comment #8 rather than make the much bigger, riskier change he suggested. This change will have no overhead on other WebKit ports. We're not even asking WebKit developers to look out for this in the future. 151039 23 michaeln 2009-09-29 14:03:38 -0700 > I think Marks objections are outlined well in comment #8. And there is an unanswered response in comment #9. In the absence of a response, four more eyes took a look, and that inspection resulted in things getting committed. Not sure how this molehill became a mountain, but here we are. So... what is the plan to surmount this newly formed mountain? (imho... this is not a productive use of time guys) 151073 24 mrowe 2009-09-29 15:21:41 -0700 A few random points: * When an objection is raised to a patch it is common courtesy to ensure that the objection is cleared up before the patch is landed. * Changing the semantics of a standard library such as SQLite is a bad idea. You've already seen that it causes subtle bugs. * Claiming that this affects "EVERY WebKit port that changes the default behavior of SQLite's BEGIN command" may be literally true, but it's a ridiculous statement to make. This affects Chrome, and only Chrome. * Claims like "this change will have no overhead on other WebKit ports" are literally true, but miss the forest for this particular tree. Chrome developers contributing to WebKit no longer see the same semantics from SQL code that every other port sees, which greatly increases the chances that they will contribute code that has subtle issues on other ports. My suggestion is that if you're unwilling, for whatever reason, to change Chrome to use the standard SQLite semantics then you should make these semantics opt-in. This could be accomplished by a PRAGMA statement executed immediately after a connection is opened. This will allow WebCore to continue to remain blissfully unaware of the non-standard semantics that you wish Chromium's use of SQLite to have. 151076 25 dglazkov 2009-09-29 15:31:01 -0700 My apologies. I had assumed -- incorrectly -- that the discussion had completed. I won't do this again. I'll let you guys hash out the specifics of this. 151096 26 fishd 2009-09-29 16:31:44 -0700 > * Changing the semantics of a standard library such as SQLite is a bad idea. > You've already seen that it causes subtle bugs. I agree in principle. However, in this case modifying SQLite behavior proved to be the better solution. It was not just a convenient hack. This is something we put together back in 2007 for Gears to address issues related to multi-process access (which Chrome obviously shares). In addition to this, we maintain several patches to SQLite. Some are in the process of being contributed to SQLite. Some have already (see for instance fts3). Others are not for various reasons. In all cases, we take on the burden of maintaining these patches because they provide us some substantial benefit. That is Chromium team's burden. When it comes to the proposed change, it is only adding specificity. It doesn't change the meaning of the code. So, in the short term at least, I don't see the harm in it. It fixes a Chromium bug and leaves other ports unmodified. I propose that we proceed with this patch, and then fork off the discussion about how to avoid it to another bug. That will entail more work, but I think it is a worthwhile endeavor. It is reasonable for us to circle back and review the decision from 2007 that brought us here. Here's the sqlite thread from 2007: http://www.mail-archive.com/sqlite-users@sqlite.org/msg28271.html 151106 27 mrowe 2009-09-29 17:03:23 -0700 While this change itself is obviously small and doesn't change behavior, I feel that the deeper issues that it raises about using custom SQLite dialects should be addressed before we start modifying WebCore. I suspect that Bugzilla isn't the best forum for that discussion. 151109 28 jorlow 2009-09-29 17:13:00 -0700 (In reply to comment #27) > While this change itself is obviously small and doesn't change behavior, I feel > that the deeper issues that it raises about using custom SQLite dialects should > be addressed before we start modifying WebCore. I suspect that Bugzilla isn't > the best forum for that discussion. Sure. We can do it on WebKit-dev then? Either way, I think this patch should go in now. It fixes a bug that is currently affecting Chromium and will not (itself) affect any other port in a negative way. Darin acknowledged that there is a larger issue here that needs to be addressed, so there's no need to hold this fix hostage in order to force such a discussion to take place. 151111 29 mrowe 2009-09-29 17:16:45 -0700 (In reply to comment #28) > (In reply to comment #27) > > While this change itself is obviously small and doesn't change behavior, I feel > > that the deeper issues that it raises about using custom SQLite dialects should > > be addressed before we start modifying WebCore. I suspect that Bugzilla isn't > > the best forum for that discussion. > > Sure. We can do it on WebKit-dev then? Sure. > Either way, I think this patch should go in now. It fixes a bug that is > currently affecting Chromium and will not (itself) affect any other port in a > negative way. > > Darin acknowledged that there is a larger issue here that needs to be > addressed, so there's no need to hold this fix hostage in order to force such a > discussion to take place. The comment to which you're replying was quite clear on my feelings about this. 151112 30 mrowe 2009-09-29 17:22:14 -0700 I'd like to add that I understand you're keen to see this problem fixed, but given the code has being using "BEGIN" for at least two years now I don't see why this is suddenly so urgent that we can't have a reasonable discussion to decide the appropriate course of action. 151120 31 mjs 2009-09-29 17:41:19 -0700 (In reply to comment #10) > Mark, I talked to dglazkov about this, and he brought up a good point. Every > time we execute a SQL statement, SQLite implicitly creates a transaction. So > even if we wanted to change all Chromium code that uses SQLite, but doesn't do > it through WebCore, it wouldn't be as easy as grepping for BEGIN and changing > all occurrences to BEGIN IMMEDIATE. We'd have to: > > 1. Find every SQL statement that we execute. > 2. Figure out if it goes through WebCore or not. > 3. If it doesn't, wrap each statement into a "BEGIN IMMEDIATE; " + sqlStatement > + "COMMIT;" (or similar) construct. > > Even if this might seem like the right solution, going through the entire > Chromium code base looking for SQL statements, and then wrapping each one of > them into an explicit transaction seems unreasonable to us at this point. If your change to SQLite affects every single SQL statement in Chromium, not just BEGINs, then isn't there a risk it affects every single SQL statement in WebKit, not just BEGINs? Or is there a reason that's not the case? 151124 32 mjs 2009-09-29 17:51:46 -0700 (In reply to comment #30) > I'd like to add that I understand you're keen to see this problem fixed, but > given the code has being using "BEGIN" for at least two years now I don't see > why this is suddenly so urgent that we can't have a reasonable discussion to > decide the appropriate course of action. Unless there is a reason this change is particularly time-sensitive, it's probably good to have the discussion first. I wouldn't categorically rule out accepting the change, but to me it seems strange and worrisome for Chromium to modify SQLite's behavior and then modify WebKit to work around it. It seems like there will be a risk of this approach creating future bugs, because somebody didn't test on the other SQLite variant. So let's see if we can figure out a more sustainable solution. 151129 33 mjs 2009-09-29 18:02:15 -0700 (In reply to comment #23) > > I think Marks objections are outlined well in comment #8. > > And there is an unanswered response in comment #9. In the absence of a > response, four more eyes took a look, and that inspection resulted in things > getting committed. Not sure how this molehill became a mountain, but here we > are. > > So... what is the plan to surmount this newly formed mountain? > > (imho... this is not a productive use of time guys) I agree this issue is the biggest in the world. We could live with this patch if there is truly no alternative, even though it creates a long-term testing risk. However, I don't think it's good to be so dismissive of Mark's concerns. He sees this small code change as potentially indicative of larger issues. That's worth thinking about, at least. 151135 34 michaeln 2009-09-29 18:29:29 -0700 > I agree this issue is the biggest in the world. We could live with this patch > if there is truly no alternative, even though it creates a long-term testing > risk. However, I don't think it's good to be so dismissive of Mark's concerns. > He sees this small code change as potentially indicative of larger issues. > That's worth thinking about, at least. Thnx for the courtesy of an actual reply to something i typed in here. I certainly didn't mean to be dismissive of Mark's concerns. I replied and waited, dumi followed up, we waited some more. After no response, I escalated to some chrome webkit reviewers/committers, we exchanged thoughts on what to do and life went on... and then all hell broken loose. It's been mentioned a couple of times in the course of this code review that the chrome team should probably revisit its decision to apply that SQLite patch. I buy that, several others of us do to. Any changes we make there has some ripple, all of our usages of SQLite will be affected. We could probably make the change w/o any incidence, but there is a chance of an unintended interaction somewhere. So we're not looking to make that change hastily. We will do so only with appropriate deliberation. It's also been observed that the addition of the DEFERRED keyword in webcore code should be considered a small improvement to the webcore code base irrespective of default behavior of SQLite. Adding clarity and specificity is generally good thing. Several comments have added weight to that observation. And obviously it doesn't alter the behavior of webcore at all. When i hold the two options up and look at what todo for the here and now, the answer is pretty obvious to me... a choice between a safe cosmetic change vs something that may actually carry risk. 151137 35 dumi 2009-09-29 18:33:23 -0700 Maciej, I don't think there's any testing risk here. With this patch, we do not want WebCore to do anything special for us. On the contrary, we want it to do exactly the same thing that it does for all other ports. And since our SQLite build uses different defaults, we just want to replace a SQLite standard command that depends on default values with another SQLite standard command that doesn't. That's all. > If your change to SQLite affects every single SQL statement in Chromium, not > just BEGINs, then isn't there a risk it affects every single SQL statement in > WebKit, not just BEGINs? Or is there a reason that's not the case? As far as I know, Chromium doesn't use any WebKit code that interacts with SQLite (other than the databases/storage code, but this is exactly the code that we're trying to fix in this patch). 151146 36 mjs 2009-09-29 18:49:04 -0700 (In reply to comment #35) > Maciej, I don't think there's any testing risk here. With this patch, we do not > want WebCore to do anything special for us. On the contrary, we want it to do > exactly the same thing that it does for all other ports. And since our SQLite > build uses different defaults, we just want to replace a SQLite standard > command that depends on default values with another SQLite standard command > that doesn't. That's all. > > > If your change to SQLite affects every single SQL statement in Chromium, not > > just BEGINs, then isn't there a risk it affects every single SQL statement in > > WebKit, not just BEGINs? Or is there a reason that's not the case? > > As far as I know, Chromium doesn't use any WebKit code that interacts with > SQLite (other than the databases/storage code, but this is exactly the code > that we're trying to fix in this patch). That doesn't really answer my question - if non-BEGIN statements in Chromium's code could be affected by a change to SQLite BEGIN behavior, why aren't non-BEGIN statements in WebKit code affected? Is the change asymmetric somehow? This patch only changes a BEGIN and not other statements. This isn't necessarily a showstopper, I'd just like to understand the issue. 151151 37 michaeln 2009-09-29 19:03:02 -0700 > That doesn't really answer my question - if non-BEGIN statements in Chromium's > code could be affected by a change to SQLite BEGIN behavior, why aren't > non-BEGIN statements in WebKit code affected? Is the change asymmetric somehow? > This patch only changes a BEGIN and not other statements. This isn't > necessarily a showstopper, I'd just like to understand the issue. Thats a good question. I'm not sure if our patch has any affect on the implicit transactions started around 'naked' statements. Our patch is to the parser, so there's a good chance that it doesn't affect non-BEGIN statements, but I don't know that for a fact. Scott probably know the answer to that question. 151154 38 dglazkov 2009-09-29 19:22:46 -0700 As we spoke over IRC, I think the following plan materialized: * dumi & shess to meet tomorrow and figure out the impact of rolling out BEGIN IMMEDIATE patch * if the roll out is not possible, figure out the effort involved in adding a PRAGMA option (or even direct SQLite API) to change transaction mode run-time. * If the effort is more than knee-high, we'll regroup and work w/Maciej & Mark until we have a consensus on how to proceed. This effort may involve alcohol. 151156 39 mjs 2009-09-29 19:28:58 -0700 (In reply to comment #38) > * If the effort is more than knee-high, we'll regroup and work w/Maciej & Mark > until we have a consensus on how to proceed. This effort may involve alcohol. Wait, no alcohol until step 3? :-) 151162 40 michaeln 2009-09-29 21:27:14 -0700 Oh well, so much for avoiding the hoop jumping. 151300 41 michaeln 2009-09-30 11:25:07 -0700 > Thats a good question. I'm not sure if our patch has any affect on the implicit > transactions started around 'naked' statements. Our patch is to the parser, so > there's a good chance that it doesn't affect non-BEGIN statements, but I don't > know that for a fact. Scott probably know the answer to that question. To complete the jump thru this particular hoop... >> scott said >> Re Michael's #37, I believe all implicit statements use the >> appropriate transaction type from the get-go > > i said > Clarification please... by 'appropiate trans type' do you mean... > a. IMMEDIATE since we've whacked the parser in that way > b. appropriate for the statement type, independent of our parser whackings > I think you mean the latter. scott said I mean many different things, and all of them mean that it doesn't matter. Possibilities: a. the BEGIN default is changed in the parser, so implicit statements don't change their behavior at all. b. the compiler knows enough to compile the statement to BEGIN IMMEDIATE if it's an update, or BEGIN DEFERRED if not, again our change wouldn't affect this. c. regardless, if an implicit statement returns SQLITE_BUSY the appropriate response is to execute it again. This is correct and works right regardless of whether it starts with an IMMEDIATE transaction or upgrades it midway through. Basically, I think implicit transactions are a red herring in this discussion. 162792 42 dumi 2009-11-11 21:43:31 -0800 We reverted our SQLite patch to make BEGIN default to BEGIN DEFERRED, thus making this patch unnecessary. 40098 2009-09-24 20:27:55 -0700 2009-09-29 11:56:56 -0700 patch patch text/plain 2053 dumi SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA0ODc0NSkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTkgQEAKKzIwMDktMDktMjQgIER1bWl0cnUgRGFuaWxpdWMgIDxkdW1pQGNocm9t aXVtLm9yZz4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAg ICBTdGFydGluZyBhbGwgcmVhZC1vbmx5IHRyYW5zYWN0aW9ucyB3aXRoIGFuIGV4cGxpY2l0IEJF R0lOCisgICAgICAgIERJRkVSUkVEIGNvbW1hbmQgaW5zdGVhZCBvZiBCRUdJTiwgc2luY2Ugc29t ZSBwb3J0cyAoY2hyb21pdW0pCisgICAgICAgIG1pZ2h0IGNvbXBpbGUgdGhlaXIgb3duIFNRTGl0 ZSBsaWJyYXJ5IGFuZCBzZXQgQkVHSU4gdG8gQkVHSU4KKyAgICAgICAgSU1NRURJQVRFIGJ5IGRl ZmF1bHQ7IHdoaWNoIHdvdWxkIHJlc3VsdCBpbiBhIGRlYWRsb2NrIGluIGNhc2Ugb2YKKyAgICAg ICAgdHdvIGNvbmN1cnJlbnQgcmVhZC1vbmx5IHRyYW5zYWN0aW9ucyBvbiB0aGUgc2FtZSBEQiwg YW5kIHdvdWxkCisgICAgICAgIHVubmVjZXNzYXJpbHkgZGVsYXkgb3RoZXIgcG90ZW50aWFsIHRy YW5zYWN0aW9ucyB0byB0aGUgc2FtZSBEQi4KKworICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0 Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9Mjk3MjkKKworICAgICAgICAqIHBsYXRmb3JtL3NxbC9TUUxp dGVUcmFuc2FjdGlvbi5jcHA6CisgICAgICAgIChXZWJDb3JlOjpTUUxpdGVUcmFuc2FjdGlvbjo6 YmVnaW4pOgorCiAyMDA5LTA5LTI0ICBKb2huIEdyZWdnICA8am9obm55Z0Bnb29nbGUuY29tPgog CiAgICAgICAgIFJldmlld2VkIGJ5IEVyaWMgU2VpZGVsLgpJbmRleDogV2ViQ29yZS9wbGF0Zm9y bS9zcWwvU1FMaXRlVHJhbnNhY3Rpb24uY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvcGxhdGZv cm0vc3FsL1NRTGl0ZVRyYW5zYWN0aW9uLmNwcAkocmV2aXNpb24gNDg3NDApCisrKyBXZWJDb3Jl L3BsYXRmb3JtL3NxbC9TUUxpdGVUcmFuc2FjdGlvbi5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTU0 LDggKzU0LDE0IEBAIHZvaWQgU1FMaXRlVHJhbnNhY3Rpb246OmJlZ2luKCkKICAgICAgICAgLy8g YW55IHN0YXRlbWVudHMuIElmIHRoYXQgaGFwcGVucywgdGhpcyB0cmFuc2FjdGlvbiB3aWxsIGZh aWwuCiAgICAgICAgIC8vIGh0dHA6Ly93d3cuc3FsaXRlLm9yZy9sYW5nX3RyYW5zYWN0aW9uLmh0 bWwKICAgICAgICAgLy8gaHR0cDovL3d3dy5zcWxpdGUub3JnL2xvY2tpbmd2My5odG1sI2xvY2tp bmcKKyAgICAgICAgLy8KKyAgICAgICAgLy8gQ2FsbCBCRUdJTiBERUZFUlJFRCBleHBsaWNpdGx5 IGZvciBhIHJlYWQtb25seSB0cmFuc2FjdGlvbi4KKyAgICAgICAgLy8gT3RoZXJ3aXNlLCBhIHBv cnQgbWlnaHQgdXNlIGEgU1FMaXRlIGxpYnJhcnkgdGhhdCB3YXMgYnVpbHQKKyAgICAgICAgLy8g dG8gaW50ZXJwcmV0IEJFR0lOIGFzIEJFR0lOIElNTUVESUFURSwgd2hpY2ggd291bGQgbGVhZCB0 bworICAgICAgICAvLyBhIGRlYWRsb2NrIHdoZW5ldmVyIHR3byByZWFkIHRyYW5zYWN0aW9ucyBv biB0aGUgc2FtZSBEQgorICAgICAgICAvLyBhcmUgc2NoZWR1bGVkIGNvbmN1cnJlbnRseS4KICAg ICAgICAgaWYgKG1fcmVhZE9ubHkpCi0gICAgICAgICAgICBtX2luUHJvZ3Jlc3MgPSBtX2RiLmV4 ZWN1dGVDb21tYW5kKCJCRUdJTjsiKTsKKyAgICAgICAgICAgIG1faW5Qcm9ncmVzcyA9IG1fZGIu ZXhlY3V0ZUNvbW1hbmQoIkJFR0lOIERFRkVSUkVEOyIpOwogICAgICAgICBlbHNlCiAgICAgICAg ICAgICBtX2luUHJvZ3Jlc3MgPSBtX2RiLmV4ZWN1dGVDb21tYW5kKCJCRUdJTiBJTU1FRElBVEU7 Iik7CiAgICAgICAgIG1fZGIubV90cmFuc2FjdGlvbkluUHJvZ3Jlc3MgPSBtX2luUHJvZ3Jlc3M7 Cg== 40315 2009-09-29 11:56:56 -0700 2009-09-29 13:05:19 -0700 patch patch text/plain 2800 dumi SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA0ODc0NSkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTkgQEAKKzIwMDktMDktMjkgIER1bWl0cnUgRGFuaWxpdWMgIDxkdW1pQGNocm9t aXVtLm9yZz4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAg ICBTdGFydGluZyBhbGwgcmVhZC1vbmx5IHRyYW5zYWN0aW9ucyB3aXRoIGFuIGV4cGxpY2l0IEJF R0lOCisgICAgICAgIERFRkVSUkVEIGNvbW1hbmQgaW5zdGVhZCBvZiBCRUdJTiwgc2luY2Ugc29t ZSBwb3J0cyAoY2hyb21pdW0pCisgICAgICAgIG1pZ2h0IGNvbXBpbGUgdGhlaXIgb3duIFNRTGl0 ZSBsaWJyYXJ5IGFuZCBzZXQgQkVHSU4gdG8gQkVHSU4KKyAgICAgICAgSU1NRURJQVRFIGJ5IGRl ZmF1bHQ7IHdoaWNoIHdvdWxkIHJlc3VsdCBpbiBhIGRlYWRsb2NrIGluIGNhc2Ugb2YKKyAgICAg ICAgdHdvIGNvbmN1cnJlbnQgcmVhZC1vbmx5IHRyYW5zYWN0aW9ucyBvbiB0aGUgc2FtZSBEQiwg YW5kIHdvdWxkCisgICAgICAgIHVubmVjZXNzYXJpbHkgZGVsYXkgb3RoZXIgcG90ZW50aWFsIHRy YW5zYWN0aW9ucyB0byB0aGUgc2FtZSBEQi4KKworICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0 Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9Mjk3MjkKKworICAgICAgICAqIHBsYXRmb3JtL3NxbC9TUUxp dGVUcmFuc2FjdGlvbi5jcHA6CisgICAgICAgIChXZWJDb3JlOjpTUUxpdGVUcmFuc2FjdGlvbjo6 YmVnaW4pOgorCiAyMDA5LTA5LTI0ICBKb2huIEdyZWdnICA8am9obm55Z0Bnb29nbGUuY29tPgog CiAgICAgICAgIFJldmlld2VkIGJ5IEVyaWMgU2VpZGVsLgpJbmRleDogV2ViQ29yZS9wbGF0Zm9y bS9zcWwvU1FMaXRlVHJhbnNhY3Rpb24uY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvcGxhdGZv cm0vc3FsL1NRTGl0ZVRyYW5zYWN0aW9uLmNwcAkocmV2aXNpb24gNDg3NDApCisrKyBXZWJDb3Jl L3BsYXRmb3JtL3NxbC9TUUxpdGVUcmFuc2FjdGlvbi5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTQ3 LDE1ICs0NywyMSBAQCB2b2lkIFNRTGl0ZVRyYW5zYWN0aW9uOjpiZWdpbigpCiB7CiAgICAgaWYg KCFtX2luUHJvZ3Jlc3MpIHsKICAgICAgICAgQVNTRVJUKCFtX2RiLm1fdHJhbnNhY3Rpb25JblBy b2dyZXNzKTsKLSAgICAgICAgLy8gQ2FsbCBCRUdJTiBJTU1FRElBVEUgZm9yIGEgd3JpdGUgdHJh bnNhY3Rpb24gdG8gYWNxdWlyZQotICAgICAgICAvLyBhIFJFU0VSVkVEIGxvY2sgb24gdGhlIERC IGZpbGUuIE90aGVyd2lzZSwgYW5vdGhlciB3cml0ZQotICAgICAgICAvLyB0cmFuc2FjdGlvbiAo b24gYW5vdGhlciBjb25uZWN0aW9uKSBjb3VsZCBtYWtlIGNoYW5nZXMKLSAgICAgICAgLy8gdG8g dGhlIHNhbWUgREIgZmlsZSBiZWZvcmUgdGhpcyB0cmFuc2FjdGlvbiBnZXRzIHRvIGV4ZWN1dGUK LSAgICAgICAgLy8gYW55IHN0YXRlbWVudHMuIElmIHRoYXQgaGFwcGVucywgdGhpcyB0cmFuc2Fj dGlvbiB3aWxsIGZhaWwuCisgICAgICAgIC8vIEZvciByZWFkLW9ubHkgdHJhbnNhY3Rpb25zLCBj YWxsIEJFR0lOIERFRkVSUkVEIGV4cGxpY2l0bHkuCisgICAgICAgIC8vIE90aGVyd2lzZSwgYSBw b3J0IG1pZ2h0IHVzZSBhIFNRTGl0ZSBsaWJyYXJ5IHRoYXQgd2FzIGJ1aWxkCisgICAgICAgIC8v IHRvIGludGVycHJldCBCRUdJTiBhcyBCRUdJTiBJTU1FRElBVEUsIHdoaWNoIHdvdWxkIGxlYWQg dG8KKyAgICAgICAgLy8gYSBkZWFkbG9jayB3aGVuZXZlciB0d28gcmVhZCB0cmFuc2FjdGlvbnMg b24gdGhlIHNhbWUgREIKKyAgICAgICAgLy8gYXJlIHNjaGVkdWxlZCBjb25jdXJyZW50bHkuCisg ICAgICAgIC8vIEZvciB3cml0ZSB0cmFuc2FjdGlvbnMsIGNhbGwgQkVHSU4gSU1NRURJQVRFIHRv IGFjcXVpcmUKKyAgICAgICAgLy8gYSBSRVNFUlZFRCBsb2NrIG9uIHRoZSBEQiBmaWxlIGJlZm9y ZSB0aGUgdHJhbnNhY3Rpb24KKyAgICAgICAgLy8gY2FsbGJhY2sgaXMgZXhlY3V0ZWQuIE90aGVy d2lzZSwgYW5vdGhlciB3cml0ZSB0cmFuc2FjdGlvbgorICAgICAgICAvLyAob24gYW5vdGhlciBj b25uZWN0aW9uKSBjb3VsZCBtYWtlIGNoYW5nZXMgdG8gdGhlIHNhbWUgREIgZmlsZQorICAgICAg ICAvLyBiZWZvcmUgdGhpcyB0cmFuc2FjdGlvbiBnZXRzIHRvIGV4ZWN1dGUgYW55IHN0YXRlbWVu dHMuCisgICAgICAgIC8vIElmIHRoYXQgaGFwcGVucywgdGhpcyB0cmFuc2FjdGlvbiB3aWxsIGZh aWwuCiAgICAgICAgIC8vIGh0dHA6Ly93d3cuc3FsaXRlLm9yZy9sYW5nX3RyYW5zYWN0aW9uLmh0 bWwKICAgICAgICAgLy8gaHR0cDovL3d3dy5zcWxpdGUub3JnL2xvY2tpbmd2My5odG1sI2xvY2tp bmcKICAgICAgICAgaWYgKG1fcmVhZE9ubHkpCi0gICAgICAgICAgICBtX2luUHJvZ3Jlc3MgPSBt X2RiLmV4ZWN1dGVDb21tYW5kKCJCRUdJTjsiKTsKKyAgICAgICAgICAgIG1faW5Qcm9ncmVzcyA9 IG1fZGIuZXhlY3V0ZUNvbW1hbmQoIkJFR0lOIERFRkVSUkVEOyIpOwogICAgICAgICBlbHNlCiAg ICAgICAgICAgICBtX2luUHJvZ3Jlc3MgPSBtX2RiLmV4ZWN1dGVDb21tYW5kKCJCRUdJTiBJTU1F RElBVEU7Iik7CiAgICAgICAgIG1fZGIubV90cmFuc2FjdGlvbkluUHJvZ3Jlc3MgPSBtX2luUHJv Z3Jlc3M7Cg==