bug#18892: few test failure with 'grep-2.20.72-d512'
Your total free memory is obviously larger than 2GiB, but remember that what's listed there is the total, while the offending usage required a *contiguous* 2GiB region. On Sat, Nov 1, 2014 at 7:56 PM, Bruce Dubbs bruce.du...@gmail.com wrote: Jim Meyering wrote: On Wed, Oct 29, 2014 at 2:56 PM, Bruce Dubbs bruce.du...@gmail.com wrote: ... http://meyering.net/grep/grep-2.20.72-d512.tar.xz ... Linux From Scratch 7.6 configure and make were clean. $ env RUN_EXPENSIVE_TESTS=yes make -k check big-match: skipped test: not enough main memory to run the test sjis-mb: skipped test: SJIS locale not found I do have 8G of memory. That test fails when grep fails to allocate enough space to hold a 2GiB line. No big deal, and not hard to imaging happening with a few applications in 8GiB of RAM. Curious though. It should have been OK. I did not have any gui running at the time. Even if RAM was full, swap should have handled it. $ free total used free sharedbuffers cached Mem: 810597223800125725960880 610460 326820 -/+ buffers/cache: 14427326663240 Swap:10485756 3216 10482540 -- Bruce
bug#18892: few test failure with 'grep-2.20.72-d512'
Hello, On 11/01/2014 10:39 PM, Paul Eggert wrote: Assaf Gordon wrote: $ ../../../src/grep -r '^' ; echo $? a:a b:b ../../../src/grep: c: Inappropriate file type or format ../../../src/grep: d: Inappropriate file type or format ../../../src/grep: e: Inappropriate file type or format 2 What system calls is this 'grep' executing? What's the output of ktrace and kdump? Attached is the ktrace+tdump output of running the command. The error appears on line 217 (open() returns -1 for file c), though similar errors stemming from 'fstat' for files a,b are ignored (lines 150,191). - Assaf netbsd.grp.out.txt.xz Description: application/xz
bug#18892: few test failure with 'grep-2.20.72-d512'
Jim Meyering wrote: Your total free memory is obviously larger than 2GiB, but remember that what's listed there is the total, while the offending usage required a *contiguous* 2GiB region. My understanding of the kernel is that it allocates in 4K blocks and maps them to user space to appear to be contiguous. If I write a program that does: size_t size = 0xA000; // 2,684,354,560 char* mem = (char*) malloc( size ); size_t i; for ( i = 0; i size; i++, mem++ ) *mem='A'; There are no problems, but it does take about 9 seconds on my system. The start address is 7ffa5405d010. The end address is 7ffaf405d010. What am I missing? -- Bruce On Sat, Nov 1, 2014 at 7:56 PM, Bruce Dubbs bruce.du...@gmail.com wrote: Jim Meyering wrote: On Wed, Oct 29, 2014 at 2:56 PM, Bruce Dubbs bruce.du...@gmail.com wrote: ... http://meyering.net/grep/grep-2.20.72-d512.tar.xz ... Linux From Scratch 7.6 configure and make were clean. $ env RUN_EXPENSIVE_TESTS=yes make -k check big-match: skipped test: not enough main memory to run the test sjis-mb: skipped test: SJIS locale not found I do have 8G of memory. That test fails when grep fails to allocate enough space to hold a 2GiB line. No big deal, and not hard to imaging happening with a few applications in 8GiB of RAM. Curious though. It should have been OK. I did not have any gui running at the time. Even if RAM was full, swap should have handled it. $ free total used free sharedbuffers cached Mem: 810597223800125725960880 610460 326820 -/+ buffers/cache: 14427326663240 Swap:10485756 3216 10482540 -- Bruce
bug#18892: few test failure with 'grep-2.20.72-d512'
Assaf Gordon assafgor...@gmail.com wrote:
On 11/01/2014 10:39 PM, Paul Eggert wrote:
Assaf Gordon wrote:
$ ../../../src/grep -r '^' ; echo $?
a:a
b:b
../../../src/grep: c: Inappropriate file type or format
../../../src/grep: d: Inappropriate file type or format
../../../src/grep: e: Inappropriate file type or format
2
What system calls is this 'grep' executing? What's the output of ktrace
and kdump?
Attached is the ktrace+tdump output of running the command.
The error appears on line 217 (open() returns -1 for file c),
though similar errors stemming from 'fstat' for files a,b are ignored (lines
150,191).
- Assaf
NetBSD returns errno == EFTYPE in open with O_NOFOLLOW for symlink
instead of errno == ELOOP which POSIX says. Similarly, Tru64 returns
errno == ENOTSUP. So I added them to ignorable list.
From 163e4e868fce733c494e6d3154e6adf97c64de9c Mon Sep 17 00:00:00 2001
From: Norihiro Tanaka nori...@kcn.ne.jp
Date: Mon, 3 Nov 2014 14:04:40 +0900
Subject: [PATCH] grep: fix symlink non-conforming to POSIX
Reported by Assaf Gordon in: http://bugs.gnu.org/18892
* src/grep.c (grepfile): Also treat EFTYPE (if defined) and ENOTSUP
as ELOOP.
---
src/grep.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/src/grep.c b/src/grep.c
index 0a4ac27..559c623 100644
--- a/src/grep.c
+++ b/src/grep.c
@@ -1519,8 +1519,26 @@ grepfile (int dirdesc, char const *name, bool follow,
bool command_line)
int desc = openat_safer (dirdesc, name, O_RDONLY | (follow ? 0 :
O_NOFOLLOW));
if (desc 0)
{
- if (follow || (errno != ELOOP errno != EMLINK))
-suppressible_error (filename, errno);
+ if (!follow)
+switch (errno)
+ {
+ case ELOOP:
+
+/* With open (symlink, O_NOFOLLOW|...), POSIX says
+ errno == ELOOP, but some operating systems do not conform
+ to the standard. */
+#ifdef EFTYPE
+/* NetBSD uses errno == EFTYPE. */
+ case EFTYPE:
+#endif
+/* FreeBSD 8.1 uses errno == EMLINK. */
+ case EMLINK:
+
+/* Tru64 5.1B uses errno == ENOTSUP. */
+ case ENOTSUP:
+return true;
+ }
+ suppressible_error (filename, errno);
return true;
}
return grepdesc (desc, command_line);
--
2.1.3
bug#18892: few test failure with 'grep-2.20.72-d512'
Norihiro Tanaka wrote: /* Tru64 5.1B uses errno == ENOTSUP. */ Ah, I see that you were working on the same bug I was. I don't think we need to worry about Tru64, partly because ENOTSUP would be troublesome anyway (does it mean that O_NOFOLLOW isn't supported? if so, 'grep' has other problems), partly because HP stopped supporting Tru64 in December 2012 and typically we can stop supporting a platform once its supplier stops.
bug#18892: few test failure with 'grep-2.20.72-d512'
Norihiro Tanaka wrote: /* Tru64 5.1B uses errno == ENOTSUP. */ Ah, I see that you were working on the same bug I was. I don't think we need to worry about Tru64, partly because ENOTSUP would be troublesome anyway (does it mean that O_NOFOLLOW isn't supported? if so, 'grep' has other problems), partly because HP stopped supporting Tru64 in December 2012 and typically we can stop supporting a platform once its supplier stops. Thanks, I agree you. And I feel your work is more elegant than my. (^_^)
