bug#11956: misc/tty-eof: sometimes failure under heavy load
FAIL: misc/tty-eof (exit: 1) F: 1: YSBiCg== F: 1: a b F: 1: 780509149 4 F: 1: a b F: 1: a b F: 1: a b F: 1: a b F: 1: a b F: 1: 7557d2f3a6ad1a3a8ebd23a94ab0c642 - F: 1: 1a b F: 1: 000 020141 005142 F: 1: a b F: 1: F: 1:a b F: 1: 90ce62edf2fe4940e041a68b13e7b5f9d02bbf51 - F: 1: afa36e61f94d23fa2869cc1ca3c7a0855ecb7f3d3305e446e7566d1f - F: 1: 01186fcf04b4b447f393e552964c08c7b419c1ad7a25c342a0b631b1967d3a27 - F: 1: adf433b1ea7db8dec7ca64f88f4c8bc5403a1ac1d3540ae0229c79fc8d84e3db4dd9616605c61215ee7c50da0a97d0e2 - F: 1: ae206702ea661de518d6451ee5b76fe0120429239b73838301991a294bc2628c0b9bbe79d06b1ab0610a66e9ce7d7e16cdcbdc244058befefc03c5d9cce54357 - F: 1: a b tty-eof: sort didn't produce expected output F: 1: 08271 1 tty-eof: tac didn't produce expected output F: 1: a b F: 1: a b F: 1: a F: 1: a b F: 1: a b F: 1: 1 2 4 I was running "make check-very-expensive -j 10 -l 4", and as misc/tty-eof is quite at the top, "make" maybe didn't have a chance to balance to load 4 yet. It happens only under heavy load (CPU and disk), but I can not reproduce it under "normal" conditions. However, with "-j 10 -l 4", I hit it quite regularly (1 out of 4 times). And sometimes, the "tac" error message is not there, only the "sort" error is there. Any idea what is going on? Have a nice day, Berny
bug#11965: version 8.17: cp/fiemap-perf test failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I can send you the test-suite.log if you think it's important (but don't want to clog up your inboxes unnecessarily if you don't). If it makes any difference, I'm still using an ext2 filesystem (the test is skipped on ext3); if that's the problem then perhaps just add to tests/cp/fiemap-perf the lines: df -t ext2 . >/dev/null && skip_ "ext2 has known slow FIEMAP scanning" (by analogy with the ext3 case which you already screen for)? I'm not subscribed, so please to cc any replies to me. Yours, Andrew Warshall -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQBXqMAAoJEESPRWh79T7tiNYH/RBDtM4B5jgmneZRUbnhiSUe BtIkCTTEltmr5G0r/jh2SkVzf+JhAJ9ROs3VHjFUcHXekNf/6WvWQky9fv0AxKX4 WyWRhdAX3Z1/KkUre0hFS/GGq1gThT77H283pGIeJ+v+xOgz/G6MUgQ/3dlSCVy5 Jkpc+o8gDopfNsYUKbFLH2XhKExXh93MkIgxZNpfqebJpmXmPxLN8w/ogdT8LNiA Lb1jR07REz2iLOWgY8+of6pCFXjF20d+zDYTfReyuMJYNoD389LWpchyGdoYCnWo TgEL4S/08k6COZ+Csmwv/thqrzMgAD8Il3HmQs2ew90p8wQP8B+rrOV0dLAC9PI= =lgUI -END PGP SIGNATURE-
bug#11967: Bug in "uniq"
Dear Sir or Madam, I think that there is a bug in "uniq" (version 8.13). The file "bug.txt" attached consists of two lines: - the first one containing a character that looks like a "v" and a line break; - the second one containing a character that looks like a upside down "v" and a line break. In hex: E2 88 A8 0A E2 88 A7 0A When we run "uniq bug.txt" in a terminal, "uniq" outputs a single line, so "uniq" thinks that the two lines are equal, but they are not. Regards, Jaime Gaspar _ Homepage: www.jaimegaspar.com E-mail: m...@jaimegaspar.com Send any screenshot to your friends in seconds... Works in all emails, instant messengers, blogs, forums and social networks. TRY IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if2 for FREE
bug#11968: Bug in "uniq"
Dear Sir or Madam, I think that there is a bug in "uniq" (version 8.13). The file "bug.txt" attached consists of two lines: - the first one containing a character that looks like a "v" and a line break; - the second one containing a character that looks like a upside down "v" and a line break. In hex: E2 88 A8 0A E2 88 A7 0A When we run "uniq bug.txt" in a terminal, "uniq" outputs a single line, so "uniq" thinks that the two lines are equal, but they are not. Regards, Jaime Gaspar _ Homepage: www.jaimegaspar.com E-mail: m...@jaimegaspar.com Send any screenshot to your friends in seconds... Works in all emails, instant messengers, blogs, forums and social networks. TRY IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if2 for FREE ⨠â§
bug#11967: Bug in "uniq"
forcemerge 11967 11968 tag 11967 notabug thanks On 07/17/2012 12:17 PM, Jaime Gaspar wrote: > I think that there is a bug in "uniq" (version 8.13). Is this your distro's build? However, I repeated your claim with the latest coreutils.git (post-8.17)., so this is not likely to be a bug in a distro-specific multibyte patch. > > The file "bug.txt" attached consists of two lines: > - the first one containing a character that > looks like a "v" and a line break; > - the second one containing a character that > looks like a upside down "v" and a line break. > In hex: > > E2 88 A8 0A > E2 88 A7 0A Those glyphs that you describe line up with Unicode characters. I bet you are using a locale with UTF-8 character encoding. > > When we run "uniq bug.txt" in a terminal, "uniq" outputs a single line, so > "uniq" thinks that the two lines are equal, but they are not. I can reproduce your symptoms, but only when I fudge my locale: $ LC_ALL=C uniq ../bug.txt ∨ ∧ $ LC_ALL=en_US.UTF-8 uniq ../bug.txt ∨ $ Remember, 'uniq' is required by POSIX to use the same line comparison techniques as 'sort'; and 'sort' is required to use strcoll() (not strcmp) to compare lines. And in your particular choice of locale, strcoll() happens to state that '∨' and '∧' collate identically; hence uniq is correct in stating that you have a duplicated line according to your current locale. $ LC_ALL=en_US.UTF-8 sort ../bug.txt -u --debug sort: using ‘en_US.UTF-8’ sorting rules ∨ _ $ So I'm closing this as not a bug, along with a final pointer to our FAQ: https://www.gnu.org/software/coreutils/faq/#Sort-does-not-sort-in-normal-order_0021 -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#11965: version 8.17: cp/fiemap-perf test failed
On 07/17/2012 03:45 PM, Andrew D Warshall wrote: > I can send you the test-suite.log if you think it's important (but > don't want to clog up your inboxes unnecessarily if you don't). If it > makes any difference, I'm still using an ext2 filesystem (the test is > skipped on ext3); if that's the problem then perhaps just add to > tests/cp/fiemap-perf the lines: > > df -t ext2 . >/dev/null && > skip_ "ext2 has known slow FIEMAP scanning" > > (by analogy with the ext3 case which you already screen for)? > > I'm not subscribed, so please to cc any replies to me. That sounds right. I'll apply that patch in your name after some testing. Which email address would you prefer. cheers, Pádraig.
bug#11965: version 8.17: cp/fiemap-perf test failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/17/12 19:52, Pádraig Brady wrote: > Which email address would you prefer. Best to use warshall (at) 99main (dot) com. -Andrew Warshall -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQBfi8AAoJEESPRWh79T7tsA8IAKDvO5pb15Qn7hgjJWQbq7EK JdDm4OdYwK0Fg91heelwsim9ylulnblBFC7vTGfWNR7e14/HwGS798AhebEHBjs0 iB3m057tZ3vswUDsnoqm4kPp9bSJHCE7Jn8M7HeGSjbpNiKQDmYmRU75x3n7wBmP rFSk6TjVNPPcbit+sq0MZpWKI6kCvC67EkiDxuzDv12IJy7PARfJ5sSu78jL5zjn 4AwOUfCzFpE4j4SADkfTmJndcTWsNKrsZGDRcgKjV4PRmop7fiO4UGZQGwjvIBbw rkLknXXhT7lJy9uWmqwa5vuKFBSe8mAKYKU0YBLzhYMiFylAoDEele6WP0fNW2o= =WH9i -END PGP SIGNATURE-
