[augeas-devel] [PATCH] Generic square lens v2

[Francis Giraldeau]

Le 2012-08-11 00:25, David Lutterkort a écrit :
> On Thu, 2012-08-09 at 14:18 +0200, Francis Giraldeau wrote:
>> Lens square now takes lenses instead of regular expressions as arguments, as follow:
>>
>>   square left body right
>>
>> The left and right lenses must accept the same language. The left lens can be
>> either key or del, while the right lens must be del.
> 
> This is getting very close, but there's still a few issues with the
> patch. For one, there's a ton of whitespace changes in the patch - if
> you really want them, please submit them as a separate patch that _only_
> changes ws. It would be much easier to review this if it were (at least)
> two patches: one that introduces and builds an AST, and a second one
> that makes the changes to the square lens.

Of course! My apologies for the spacing crap, I think I hit CTRL-I by
mistake in Eclipse, it's the shortcut for auto-format. I will double
check the diff next time and will stop using "git commit -a", quick but
too dangerous.

> When I run valgrind on the two pass_square_* tests, there's a few
> allocation problems (valgrind output is attached)

The AST error is simple, but it turns out that the error related to the
invalid read of size 8 is quite tough. I'm able to reproduce the problem
with the master branch, and I isolated this little lens snippet to
reproduce the error, a regular lens with two levels of square, where the
test consists to put three level to verify that it should fail.

module Mini =

(* Test XML like elements up to depth 2 *)
let b = del ">" ">" . del /[a-z ]*/ "" . del "</" "</"
let xml = [ del "<" "<" . square /[a-z]+/ b . del ">" ">" ] *

let b2 = del ">" ">" . xml . del "</" "</"
let xml2 = [ del "<" "<" . square /[a-z]+/ b2 . del ">" ">" ] *

test xml2 put "<a></a>" after clear "/a/y/z" = *


The error is caused in enc_format by the strcpy. I checked these
addresses and they looks ok, no garbage, no segfault. I don't know how
to check inside glibc memory inventory to make sure that's indeed the
case, thought.

The string is of length 4 and is these bytes: 'z\003\004\0'. I checked
the strcpy assembly, and there is a MMX instruction to detect the first
null byte out of 8 from the start of the source address (in %rsi):

<__stpncpy_sse2_unaligned+45>    pcmpeqb (%rsi), xmm1
<__stpncpy_sse2_unaligned+49>    pmovmskb %xmm1,%edx

The result in %edx is: 0xfff8, that shows that all bytes are zero,
except the last 3. The whole point here is: this instruction reads 8
bytes, no matter the size of the string (here 4). Could it mislead
valgrind? It's also unlikely that strcpy is defective, google returns
nothing about this kind of error.

The most probable problem is that something is wrong with the square
lens since valgrind clearly points it, but after having passed the day
on this issue, trying to debug forward/reverse, well, I need help
because I don't understand.

Francis

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4489 bytes
Desc: Signature cryptographique S/MIME
URL: <http://listman.redhat.com/archives/augeas-devel/attachments/20120811/f2240bc9/attachment.p7s>