On Wed, Apr 16, 2014 at 9:18 AM, Alan M.= Carroll <amc@network-geographics.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> I was asked for a translation of my previous email, bonging the 4.2.1 RC0.<= br>
The problem in 4.2.0 was a shift in the set of WKS values. These are not ju= st live data but also written to the cache in the object headers so if they= change at all, it de facto invalidates the cache. The 4.2.0 crashes (TS-25= 64) are due to this, because various secondary bits of data get written inc= onsistently which in turns causes ATS to look up the wrong data for header = fields. For instance, the VARY field would be written out along with a hint= about where it was in the header. When read back in 4.2.0 ATS would use th= e stored WKS index to lookup the hint location and get the wrong location (= because VARY had shifted) and use that to find the wrong data for VARY (pos= sibly null or unallocated memory).

To fix this, 4.2.1 simply clears all the hints and rewrites them when the o= bject is read from disk if using a cache version earlier than 4.2.1. This i= gnores the stored values and uses only the current in memory values.

However, it turns out that when the object is read from disk, it may be sto= red in the ram cache. If retrieved from ram cache later, it goes through th= e same logic as if it had been loaded from disk, which includes clearing an= d rewriting the hints. The ATS logic, though, doesn't lock the object f= or this because it is expected to be read only once read from the disk. The= TS-2564 logic violates this and thereby creates a race condition between t= wo transaction both access the same object. It is possible for one to check= the valid hints for a field and then, while it is trying to retrieve the f= ield, the other transaction can clear the hints causing the field to not be= found. This leads to a crash because the logic assumes (reasonably) that i= f it's checked the hints and verified the field presence, the field is = present and will be found. If the field is not found, you get a null pointe= r dereference.

The solution is to prevent the 4.2.0 fixup from being done on objects retri= eved from the ram cache. There's no need as the fixup was done when it = was read from disk and put in the ram cache. There is no race condition for= disk reads because those are not shared until after the fixup.