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
smime.p7s
Description: Signature cryptographique S/MIME
_______________________________________________ augeas-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/augeas-devel
