Re: Fwd: Re: error.c: Unknown system error should report errno value
Hi,
On Sun, 7 Oct 2007, Jim Meyering wrote:
Martin Koeppe [EMAIL PROTECTED] wrote:
The test tests/rm/dir-nonrecur shows IMO a real bug in coreutils,
however:
rm d should fail at
remove.c:1094 with cannot remove 'd': Is a directory
but fails there with cannot remove 'd': No such file or diectory
If I remove the translation call _() around the text, then it fails
correctly with Is a directory. I think failures during translation
shouldn't change the errno reported.
Thanks for investigating.
If it's happening the way you say, then gettext must change, and fail
to restore errno. Are you using the latest version of gettext?
Why do you think that's a bug in coreutils?
Can you provide something like strace/truss output?
I just found the bug in gettext causing this trouble. Unfortunately I
didn't find a gettext mailing list. So I hope that someone maintaining
gettext is also reading this list. Or if you know the right place to
report gettext bugs, please inform me.
Gettext is 0.16.1, file dcigettext.c, function libintl_dcigettext()
(gdb) display errno
1: {data variable, no debug info} 4321340 = 13
(gdb) s
582 gl_rwlock_rdlock (tree_lock);
1: {data variable, no debug info} 4321340 = 13
(gdb) s
584 foundp = (struct known_translation_t **) tfind (search,
root, transcmp);
1: {data variable, no debug info} 4321340 = 13
(gdb) frame
#0 libintl_dcigettext (domainname=0x894d28 coreutils,
msgid1=0x41b78a `,
msgid2=0x0, plural=0, n=0, category=6) at ./dcigettext.c:584
584 foundp = (struct known_translation_t **) tfind (search,
root, transcmp);
(gdb) print errno
$1 = 13
(gdb) s
586 gl_rwlock_unlock (tree_lock);
1: {data variable, no debug info} 4321340 = 2
(gdb) print errno
$1 = 2
(gdb) q
Apparently, on interix tfind() on line 584 changes errno, before it
is saved in line 587. So the patch below should be applied.
Martin
--- dcigettext.c.orig Mon Nov 27 18:02:00 2006
+++ dcigettext.cSun Oct 14 16:34:14 2007
@@ -524,6 +524,9 @@
: n == 1 ? (char *) msgid1 : (char *) msgid2);
#endif
+ /* Preserve the `errno' value. */
+ saved_errno = errno;
+
gl_rwlock_rdlock (_nl_state_lock);
/* If DOMAINNAME is NULL, we are interested in the default domain. If
@@ -599,9 +602,6 @@
return retval;
}
#endif
-
- /* Preserve the `errno' value. */
- saved_errno = errno;
/* See whether this is a SUID binary or not. */
DETERMINE_SECURE;
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
gettext clobbers errno (was: Re: Fwd: Re: error.c: Unknown system error should report errno value)
Martin Koeppe wrote:
I just found the bug in gettext causing this trouble. Unfortunately I
didn't find a gettext mailing list.
For most GNU programs, you find the bug reporting address at the end of
the program --help output. gettext --help is in this category.
Gettext is 0.16.1, file dcigettext.c, function libintl_dcigettext()
(gdb) display errno
1: {data variable, no debug info} 4321340 = 13
(gdb) s
582 gl_rwlock_rdlock (tree_lock);
1: {data variable, no debug info} 4321340 = 13
(gdb) s
584 foundp = (struct known_translation_t **) tfind (search,
root, transcmp);
1: {data variable, no debug info} 4321340 = 13
(gdb) frame
#0 libintl_dcigettext (domainname=0x894d28 coreutils,
msgid1=0x41b78a `,
msgid2=0x0, plural=0, n=0, category=6) at ./dcigettext.c:584
584 foundp = (struct known_translation_t **) tfind (search,
root, transcmp);
(gdb) print errno
$1 = 13
(gdb) s
586 gl_rwlock_unlock (tree_lock);
1: {data variable, no debug info} 4321340 = 2
(gdb) print errno
$1 = 2
(gdb) q
Apparently, on interix tfind() on line 584 changes errno, before it
is saved in line 587. So the patch below should be applied.
Thank you for this analysis! I'm applying this patch.
2007-10-14 Bruno Haible [EMAIL PROTECTED]
* dcigettext.c (DCIGETTEXT): Save errno also around the tfind() call.
Needed because Interix 3.5 tfind() clobbers errno.
Reported by Martin Koeppe [EMAIL PROTECTED].
*** dcigettext.c14 Oct 2007 15:58:47 - 1.35
--- dcigettext.c14 Oct 2007 16:02:09 -
***
*** 522,527
--- 522,530
: n == 1 ? (char *) msgid1 : (char *) msgid2);
#endif
+ /* Preserve the `errno' value. */
+ saved_errno = errno;
+
gl_rwlock_rdlock (_nl_state_lock);
/* If DOMAINNAME is NULL, we are interested in the default domain. If
***
*** 592,604
retval = (char *) (*foundp)-translation;
gl_rwlock_unlock (_nl_state_lock);
return retval;
}
#endif
- /* Preserve the `errno' value. */
- saved_errno = errno;
-
/* See whether this is a SUID binary or not. */
DETERMINE_SECURE;
--- 595,605
retval = (char *) (*foundp)-translation;
gl_rwlock_unlock (_nl_state_lock);
+ errno = saved_errno;
return retval;
}
#endif
/* See whether this is a SUID binary or not. */
DETERMINE_SECURE;
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: gettext clobbers errno (was: Re: Fwd: Re: error.c: Unknown system error should report errno value)
Hi Bruno, On Sun, 14 Oct 2007, Bruno Haible wrote: Martin Koeppe wrote: I just found the bug in gettext causing this trouble. Unfortunately I didn't find a gettext mailing list. For most GNU programs, you find the bug reporting address at the end of the program --help output. gettext --help is in this category. Thanks. Unfortunately, this http://lists.gnu.org/archive/html/bug-gnu-gettext/ is not a valid URL (404). And I looked on http://lists.gnu.org/archive/html/ for gettext or intl and couldn't find either. Gettext is 0.16.1, file dcigettext.c, function libintl_dcigettext() Apparently, on interix tfind() on line 584 changes errno, before it is saved in line 587. So the patch below should be applied. Thank you for this analysis! I'm applying this patch. --- 595,605 retval = (char *) (*foundp)-translation; gl_rwlock_unlock (_nl_state_lock); + errno = saved_errno; Thanks for adding this. For consistency with the rest of the file it should be written as: __set_errno (saved_errno); Martin ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: gettext clobbers errno (was: Re: Fwd: Re: error.c: Unknown system error should report errno value)
Martin Koeppe wrote: Thanks. Unfortunately, this http://lists.gnu.org/archive/html/bug-gnu-gettext/ is not a valid URL (404). And I looked on http://lists.gnu.org/archive/html/ for gettext or intl and couldn't find either. The bug-gnu-gettext archives are at http://lists.gnu.org/archive/html/bug-gnu-utils/ Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value (fwd)
sorry, just noted that I forgot to add the list in reply... -- Forwarded message -- Date: Tue, 9 Oct 2007 09:49:29 +0200 (CEST) From: Martin Koeppe To: Bruno Haible Subject: Re: Fwd: Re: error.c: Unknown system error should report errno value On Tue, 9 Oct 2007, Bruno Haible wrote: Martin Koeppe wrote: Now found out, that GNULIB_SPRINTF_POSIX and REPLACE_SPRINTF are set to 0 by configure, seems to be the default value, and apparently nowhere else get touched during configure (I only see 2 occurences of these 2 variables in the whole configure), so stay 0 and sprintf(), which seq uses, isn't properly replaced. The copy of src/seq.c that I have uses asprintf(), not sprintf(), in print_numbers(). Ok, you're right. The relevant output is done by asprintf(). And by printf() in line 269. I did a grep -n printf seq.c: 69:fprintf (stderr, _(Try `%s --help' for more information.\n), 73: printf (_(\ 81: -f, --format=FORMAT use printf style floating-point FORMAT\n\ 172:/* If FORMAT is a valid printf format for a double argument, return 243: if (asprintf (x_str, fmt, x) 0 244: || asprintf (last_str, fmt, last) 0) 250: if (asprintf (x0_str, fmt, x0) 0) 269: printf (fmt, x); 299: sprintf (format_buf, %%0%d.%dLf, w, prec); 305: sprintf (format_buf, %%.%dLf, prec); 321: /* The printf(3) format used for output. */ In config.h as well as config.hin I have none of REPLACE_PRINTF, REPLACE_SPRINTF, REPLACE_ASPRINTF even mentioned. I use the snapshot 316 and just ./configure --disable-nls make, no ./bootstrap. Can you show the output of nm lib/*printf*.o ? See below. I think printf() is missing there. Martin asnprintf.o: b .bss d .data N .stab N .stabstr t .text U __fltused T _asnprintf U _vasnprintf asprintf.o: b .bss d .data N .stab N .stabstr t .text U __fltused T _asprintf U _vasprintf fprintftime.o: b .bss d .data r .rdata N .stab N .stabstr t .text U __fltused 1df0 T _fprintftime U _fputc U _fwrite t _fwrite_lowcase 0050 t _fwrite_uppcase U _mblen b _mbstate_zero U _mktime U _rpl_gmtime_r U _rpl_localtime_r U _rpl_tzset U _strftime 00a0 t _strftime_case_ U _strlen U _tolower U _toupper U _tzname printf-args.o: b .bss d .data r .rdata N .stab N .stabstr t .text U __fltused T _printf_fetchargs 0064 r _wide_null_string.2637 printf-frexp.o: b .bss d .data r .rdata N .stab N .stabstr t .text U __fltused T _printf_frexp printf-frexpl.o: b .bss d .data r .rdata N .stab N .stabstr t .text U __fltused T _printf_frexpl printf-parse.o: b .bss d .data r .rdata N .stab N .stabstr t .text U __fltused U _free U _malloc T _printf_parse U _realloc vasnprintf.o: b .bss d .data r .rdata N .stab N .stabstr t .text U ___udivdi3 U ___umoddi3 U __alloca U __fltused U _abort 0ad0 t _decimal_point_char 01b0 t _divide U _errno 0b10 t _floorlog10l U _free U _malloc U _memcpy t _multiply U _printf_fetchargs U _printf_frexp U _printf_frexpl U _printf_parse U _realloc U _rpl_frexpl U _rpl_isnanl 0cf0 t _scale10_round_decimal_long_double 0140 r _small_pow5.3568 U _snprintf U _sprintf U _strlen 1710 T _vasnprintf vasprintf.o: b .bss d .data N .stab N .stabstr t .text U __fltused U _errno U _free U _vasnprintf T _vasprintf ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value (fwd)
Martin Koeppe wrote: The relevant output is done by asprintf(). And by printf() in line 269. That's it. coreutils needs to use also printf-posix, not only vasprintf-posix. Then 'seq' should work. Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value (fwd)
On Sat, 13 Oct 2007, Bruno Haible wrote:
Martin Koeppe wrote:
The relevant output is done by asprintf(). And by printf() in line 269.
That's it. coreutils needs to use also printf-posix, not only vasprintf-posix.
Then 'seq' should work.
Or modify seq to not use printf() so that not every core-util on
interix has a static copy of it, maybe as below. This works on
interix. However, the plain printf(), at least the gnulib version,
sometimes doesn't need malloc(), it uses vasnprintf() with a fixed
buffer of 2000 chars. Only if that's not enough, malloc() is used. So
this may be a reason to not use the patch below as is.
Martin
--- seq.c.orig Thu Aug 16 14:25:11 2007
+++ seq.c Sat Oct 13 22:24:53 2007
@@ -226,7 +226,10 @@
for (i = 0; /* empty */; i++)
{
long double x = first + i * step;
-
+ char *x_str = NULL;
+ if (asprintf (x_str, fmt, x) 0)
+xalloc_die();
+
if (step 0 ? x last : last x)
{
/* If we go one past the end, but that number prints the
@@ -238,10 +241,8 @@
if (i)
{
- char *x_str = NULL;
char *last_str = NULL;
- if (asprintf (x_str, fmt, x) 0
- || asprintf (last_str, fmt, last) 0)
+ if (asprintf (last_str, fmt, last) 0)
xalloc_die ();
if (STREQ (x_str, last_str))
@@ -257,7 +258,6 @@
free (x0_str);
}
- free (x_str);
free (last_str);
}
@@ -266,7 +266,10 @@
if (i)
fputs (separator, stdout);
- printf (fmt, x);
+
+ fputs (x_str, stdout);
+ free (x_str);
+
x0 = x;
}
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
Hi Jim, hi Bruno, On Sat, 6 Oct 2007, Jim Meyering wrote: Bruno Haible [EMAIL PROTECTED] wrote: Martin Koeppe wrote: The Interix libc is built with MSVC. MSVC has no long double data type. Ok, it understands long double, but always maps that to 64-bit double. So libc's printf(), when it sees %Lg, expects 64-bit double. But Interix also has gcc. gcc OTOH has 80 bit long double (stored are 12 bytes). When I build seq with gcc, for the %Lg arg 12 bytes are reserved. This will crash then. Adding the gnulib 'vasprintf-posix' module to bootstrap.conf should do the trick. That's because the only 'long double' support that coreutils requires are: - the elementary operations, these are inlined by gcc or come from libgcc.a, - asprintf(), this comes from gnulib. The same problem with 'seq' exists on mingw and BeOS, which - like Interix - lack 'long double' support in printf(). Thanks for the suggestion. I'll probably do that. Is seq segfaulting on mingw and BeOS, too? I just tested snapshot 316 and it unfortunately doesn't work on Interix, i.e. seq is still wrong. Interix has _ before C symbols, all the following are asm symbols. The Interix libc has __vfprintf which __printf seems to use. While _printf is a weak alias for __printf, this __printf seems to call (according to nm output of libc.a) the strong __vfprintf directly, rather than its weak alias _vfprintf. So it wouldn't even suffice to (re-)define _vfprintf. Martin ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
Martin Koeppe wrote: Is seq segfaulting on mingw and BeOS, too? I just tested snapshot 316 and it unfortunately doesn't work on Interix, i.e. seq is still wrong. Can you find out why? Interix has _ before C symbols, all the following are asm symbols. The Interix libc has __vfprintf which __printf seems to use. While _printf is a weak alias for __printf, this __printf seems to call (according to nm output of libc.a) the strong __vfprintf directly, rather than its weak alias _vfprintf. So it wouldn't even suffice to (re-)define _vfprintf. I don't think this is relevant. gnulib overrides are implemented at the preprocessor level (#define, #undef), not at the linker level (asm(...)), and the names that gnulib chooses (rpl_vfprintf etc.) certainly don't collide with the ones in any libc. Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
Hi Bruno, On Tue, 9 Oct 2007, Bruno Haible wrote: Martin Koeppe wrote: Is seq segfaulting on mingw and BeOS, too? I just tested snapshot 316 and it unfortunately doesn't work on Interix, i.e. seq is still wrong. Can you find out why? Now found out, that GNULIB_SPRINTF_POSIX and REPLACE_SPRINTF are set to 0 by configure, seems to be the default value, and apparently nowhere else get touched during configure (I only see 2 occurences of these 2 variables in the whole configure), so stay 0 and sprintf(), which seq uses, isn't properly replaced. At least the generated lib/stdio.h:197-199 reads: #if 0 # if 0 # define sprintf rpl_sprintf Corresponding lib/stdio.in.h:168-170 is: #if @GNULIB_SPRINTF_POSIX@ # if @REPLACE_SPRINTF@ # define sprintf rpl_sprintf Interix has _ before C symbols, all the following are asm symbols. The Interix libc has __vfprintf which __printf seems to use. While _printf is a weak alias for __printf, this __printf seems to call (according to nm output of libc.a) the strong __vfprintf directly, rather than its weak alias _vfprintf. So it wouldn't even suffice to (re-)define _vfprintf. I don't think this is relevant. gnulib overrides are implemented at the preprocessor level (#define, #undef), not at the linker level (asm(...)), and the names that gnulib chooses (rpl_vfprintf etc.) certainly don't collide with the ones in any libc. Oh, yes. Thank you. Now I understood it. It's #defined in stdio.in.h and has nothing to do with libc. Martin ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
Martin Koeppe wrote: Now found out, that GNULIB_SPRINTF_POSIX and REPLACE_SPRINTF are set to 0 by configure, seems to be the default value, and apparently nowhere else get touched during configure (I only see 2 occurences of these 2 variables in the whole configure), so stay 0 and sprintf(), which seq uses, isn't properly replaced. The copy of src/seq.c that I have uses asprintf(), not sprintf(), in print_numbers(). Can you show the output of nm lib/*printf*.o ? Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
On Sat, 6 Oct 2007, Jim Meyering wrote:
Martin Koeppe [EMAIL PROTECTED] wrote:
The first 'Segmentation fault' with dd doesn't occur when I run just
the failing command in the src dir:
./dd cbs=4 ibs=4 conv=unblock,sync dd-in dd-out
dd-out looks fine there. So I don't currently know how to reproduce
it...
How about when you run the test with VERBOSE=yes?
If the failing test is in tests/dd/misc, you'd do this:
make -C tests/dd check TESTS=misc VERBOSE=yes
Unfortunately, I cannot reproduce this seg fault any more. It's just
fine now, also with snapshot 303. Several other tests fail due to
broken seq as already discussed.
#
2 tests fail because on Interix '\' is not a valid filename character
(other POSIX filename characters like '*' or '+' or '|' are fine),
I removed those tests for me:
--- tests/misc/md5sum.orig Sun Sep 16 09:06:25 2007
+++ tests/misc/md5sum Sun Oct 7 00:21:30 2007
@@ -50,8 +50,8 @@
{OUT=d174ab98d277d9f5a5611c2c9f419d9f f\n}],
['7', {IN= {f= '1234567890' x 8}},
{OUT=57edf4a22be3c955ac49da2e2107b67a f\n}],
- ['backslash', {IN= {.\\foo= ''}},
- {OUT=\\$degenerate .foo\n}],
+# ['backslash', {IN= {.\\foo= ''}},
+# {OUT=\\$degenerate .foo\n}],
['check-1', '--check', {AUX= {f= ''}},
{IN= {'f.md5' = $degenerate
f\n}},
{OUT=f: OK\n}],
--- tests/misc/sha1sum.orig Sun Sep 16 09:06:25 2007
+++ tests/misc/sha1sum Sun Oct 7 00:24:18 2007
@@ -56,8 +56,8 @@
{OUT=50abf5706a150990a08b2c5ea40fa0e585554732 f\n}],
['million-a', {IN= {f= 'a' x 100}},
{OUT=34aa973cd4c4daa4f61eeb2bdbad27316534016f f\n}],
- ['bs-sha', {IN= {.\\foo= ''}},
- {OUT=\\$sha_degenerate .foo\n}],
+# ['bs-sha', {IN= {.\\foo= ''}},
+# {OUT=\\$sha_degenerate .foo\n}],
# The sha1sum and md5sum drivers share a lot of code.
# Ensure that sha1sum does *not* share the part that makes
# md5sum accept BSD format.
#
The test tests/rm/deep-1 seems to cause an infinite loop or something
like that, I have to kill it always, so I disabled it for me, too.
The last lines in the test's log are:
++ exit 130
+ st=130
+ cleanup_
+ :
+ d=/srv/non-deb/coreutils/cu/tests/rm/cu-deep-1.kSpfDo3431
+ cd /srv/non-deb/coreutils/cu/tests/rm
+ chmod -R u+rwx /srv/non-deb/coreutils/cu/tests/rm/cu-deep-1.kSpfDo3431
So it seems to hang on cleanup, during chmod ... Didn't look into
this to more detail yet.
#
The test tests/rm/dir-nonrecur shows IMO a real bug in coreutils,
however:
rm d should fail at
remove.c:1094 with cannot remove 'd': Is a directory
but fails there with cannot remove 'd': No such file or diectory
If I remove the translation call _() around the text, then it fails
correctly with Is a directory. I think failures during translation
shouldn't change the errno reported.
Martin
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
rm d should fail at remove.c:1094 with cannot remove 'd': Is a directory but fails there with cannot remove 'd': No such file or diectory remove.c:1094 reads like this: error (0, errno, _(cannot remove %s), quote (full_filename (filename))); _() and quote() preserve errno, but full_filename () does not: it calls realloc() and free(). Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
On Sun, 7 Oct 2007, Jim Meyering wrote: Martin Koeppe [EMAIL PROTECTED] wrote: The test tests/rm/dir-nonrecur shows IMO a real bug in coreutils, however: rm d should fail at remove.c:1094 with cannot remove 'd': Is a directory but fails there with cannot remove 'd': No such file or diectory If I remove the translation call _() around the text, then it fails correctly with Is a directory. I think failures during translation shouldn't change the errno reported. Thanks for investigating. If it's happening the way you say, then gettext must change, and fail to restore errno. Are you using the latest version of gettext? Why do you think that's a bug in coreutils? Can you provide something like strace/truss output? truss output is attached. I added 'perror(errno=);' just before remove.c:1094, to see errno before the gettext call. I'm using gettext 0.16.1 and libiconv 1.11. I now read the gettext(3) man page. It says: errno is not modified. I only thought coreutils could use the possibility to avoid this sort of bugs by saving errno elsewhere before calling gettext(). If the gettext(3) man page is to read as errno is guaranteed not to be modified then it's a gettext() bug of course. BTW, the tests mv/dir2dir and rm/dir-no-w fail due to very probably the same issue. Will try to --disable-nls and retest. Martintracing pid 3513 getdata() getdata returned 0 getrlimit() getrlimit returned 0 pthread_inform_signals() pthread_inform_signals returned 0 unixpath2win() unixpath2win returned 0 getids() getids returned 0 getids() getids returned 0 getids() getids returned 0 getids() getids returned 0 open(/usr/lib/libintl.so.8, 0x1) open returned 4 read(4, 0x85EC18, 4096) read returned 4096 0x1000 close(4) close returned 0 unixpath2win() unixpath2win returned 0 open(/usr/lib/libc.so.3.5, 0x1) open returned 4 read(4, 0x85EBF8, 4096) read returned 4096 0x1000 close(4) close returned 0 unixpath2win() unixpath2win returned 0 open(/usr/lib/libiconv.so.2, 0x1) open returned 4 read(4, 0x85EBD8, 4096) read returned 4096 0x1000 close(4) close returned 0 unixpath2win() unixpath2win returned 0 open(/usr/share/locale//_ASCII, 0x1) open returned 4 read(4, 0x864D58, 131072) read returned 131072 0x2 close(4) close returned 0 open(/usr/share/locale//ASCII_, 0x1) open returned 4 read(4, 0x864318, 512) read returned 512 0x200 read(4, 0x884D60, 131072) read returned 0 close(4) close returned 0 pthread_rwlock_wrlock(0x564C7038) pthread_rwlock_init(0x564C7038, 0x0) pthread_rwlock_init returned 0 pthread_rwlock_wrlock returned 0 pthread_rwlock_unlock(0x564C7038) pthread_rwlock_unlock returned 0 pthread_rwlock_wrlock(0x564C7038) pthread_rwlock_wrlock returned 0 pthread_rwlock_unlock(0x564C7038) pthread_rwlock_unlock returned 0 isatty(0) isatty returned 0 getids() getids returned 0 lstat(d, 0x04E80B28) lstat ret: 0 dev: 0x4c000d082e ino: 0x7ff90178 getids() getids returned 0 unlink() unlink failed: errno 1, Operation not permitted write(2, 0x85EAA0, 23) errno=: Is a directory write returned 23 0x17 pthread_rwlock_rdlock(0x564C7038) pthread_rwlock_rdlock returned 0 pthread_rwlock_rdlock(0x564C7030) pthread_rwlock_init(0x564C7030, 0x0) pthread_rwlock_init returned 0 pthread_rwlock_rdlock returned 0 pthread_rwlock_unlock(0x564C7030) pthread_rwlock_unlock returned 0 getids() getids returned 0 getids() getids returned 0 getids() getids returned 0 getids() getids returned 0 pthread_rwlock_unlock(0x564C7038) pthread_rwlock_unlock returned 0 pthread_rwlock_rdlock(0x564C7038) pthread_rwlock_rdlock returned 0 pthread_rwlock_rdlock(0x564C7030) pthread_rwlock_rdlock returned 0 pthread_rwlock_unlock(0x564C7030) pthread_rwlock_unlock returned 0 pthread_rwlock_unlock(0x564C7038) pthread_rwlock_unlock returned 0 pthread_rwlock_rdlock(0x564C7038) pthread_rwlock_rdlock returned 0 pthread_rwlock_rdlock(0x564C7030) pthread_rwlock_rdlock returned 0 pthread_rwlock_unlock(0x564C7030) pthread_rwlock_unlock returned 0 pthread_rwlock_unlock(0x564C7038) pthread_rwlock_unlock returned 0 write(2, 0x85F278, 6) ./rm: write returned 6 write(2, 0x85EE64, 17) cannot remove `d'write returned 17 0x11 write(2, 0x85EE48, 27) : No such file or directorywrite returned 27 0x1B write(2, 0x77DC2F9B, 1) write returned 1 close(0) close returned 0 close(1) close returned 0 close(2) close returned 0 exit(1) process exited with status 1 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
Bruno Haible [EMAIL PROTECTED] wrote:
rm d should fail at
remove.c:1094 with cannot remove 'd': Is a directory
but fails there with cannot remove 'd': No such file or diectory
remove.c:1094 reads like this:
error (0, errno, _(cannot remove %s),
quote (full_filename (filename)));
_() and quote() preserve errno, but full_filename () does not: it calls
realloc() and free().
Good catch. I've fixed that:
From 035a5ca2b0fb83ca179ed7739e18bb60437bc525 Mon Sep 17 00:00:00 2001
From: Jim Meyering [EMAIL PROTECTED]
Date: Sun, 7 Oct 2007 21:55:42 +0200
Subject: [PATCH] Don't let a helper function modify errno.
* src/remove.c (full_filename_): Save and restore errno.
Spotted by Bruno Haible.
Signed-off-by: Jim Meyering [EMAIL PROTECTED]
---
ChangeLog|4
src/remove.c |6 +-
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 157f126..1c3b257 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,9 @@
2007-10-07 Jim Meyering [EMAIL PROTECTED]
+ Don't let a helper function modify errno.
+ * src/remove.c (full_filename_): Save and restore errno.
+ Spotted by Bruno Haible.
+
Reflect 2-3 GPL copyright version update in gnulib.
* gl/lib/tempname.h: Update copyright from gnulib.
* gl/lib/tempname.c: Likewise.
diff --git a/src/remove.c b/src/remove.c
index 3cbfe66..4f91dd4 100644
--- a/src/remove.c
+++ b/src/remove.c
@@ -305,7 +305,8 @@ right_justify (char *dst, size_t dst_len, const char *src,
size_t src_len,
/* Using the global directory name obstack, create the full name FILENAME.
Return it in sometimes-realloc'd space that should not be freed by the
caller. Realloc as necessary. If realloc fails, use a static buffer
- and put as long a suffix in that buffer as possible. */
+ and put as long a suffix in that buffer as possible. Be careful not
+ to change errno. */
#define full_filename(Filename) full_filename_ (ds, Filename)
static char *
@@ -313,6 +314,7 @@ full_filename_ (Dirstack_state const *ds, const char
*filename)
{
static char *buf = NULL;
static size_t n_allocated = 0;
+ int saved_errno = errno;
size_t dir_len = obstack_object_size (ds-dir_stack);
char *dir_name = obstack_base (ds-dir_stack);
@@ -350,6 +352,7 @@ full_filename_ (Dirstack_state const *ds, const char
*filename)
memcpy (static_buf, ELLIPSES_PREFIX,
sizeof (ELLIPSES_PREFIX) - 1);
}
+ errno = saved_errno;
return p;
}
@@ -372,6 +375,7 @@ full_filename_ (Dirstack_state const *ds, const char
*filename)
assert (strlen (buf) + 1 == n_bytes_needed);
}
+ errno = saved_errno;
return buf;
}
--
1.5.3.4.206.g58ba4
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
Martin Koeppe [EMAIL PROTECTED] wrote: The first 'Segmentation fault' with dd doesn't occur when I run just the failing command in the src dir: ./dd cbs=4 ibs=4 conv=unblock,sync dd-in dd-out dd-out looks fine there. So I don't currently know how to reproduce it... How about when you run the test with VERBOSE=yes? If the failing test is in tests/dd/misc, you'd do this: make -C tests/dd check TESTS=misc VERBOSE=yes ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
Martin Koeppe wrote: The Interix libc is built with MSVC. MSVC has no long double data type. Ok, it understands long double, but always maps that to 64-bit double. So libc's printf(), when it sees %Lg, expects 64-bit double. But Interix also has gcc. gcc OTOH has 80 bit long double (stored are 12 bytes). When I build seq with gcc, for the %Lg arg 12 bytes are reserved. This will crash then. Adding the gnulib 'vasprintf-posix' module to bootstrap.conf should do the trick. That's because the only 'long double' support that coreutils requires are: - the elementary operations, these are inlined by gcc or come from libgcc.a, - asprintf(), this comes from gnulib. The same problem with 'seq' exists on mingw and BeOS, which - like Interix - lack 'long double' support in printf(). Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
Bruno Haible [EMAIL PROTECTED] wrote: Martin Koeppe wrote: The Interix libc is built with MSVC. MSVC has no long double data type. Ok, it understands long double, but always maps that to 64-bit double. So libc's printf(), when it sees %Lg, expects 64-bit double. But Interix also has gcc. gcc OTOH has 80 bit long double (stored are 12 bytes). When I build seq with gcc, for the %Lg arg 12 bytes are reserved. This will crash then. Adding the gnulib 'vasprintf-posix' module to bootstrap.conf should do the trick. That's because the only 'long double' support that coreutils requires are: - the elementary operations, these are inlined by gcc or come from libgcc.a, - asprintf(), this comes from gnulib. The same problem with 'seq' exists on mingw and BeOS, which - like Interix - lack 'long double' support in printf(). Thanks for the suggestion. I'll probably do that. Is seq segfaulting on mingw and BeOS, too? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
Jim Meyering wrote: Is seq segfaulting on mingw and BeOS, too? On BeOS, 'seq' is producing junk output (totally out-of-range numbers) but not segfaulting. As a consequence, the rm/readdir-bug test fails. On mingw, I don't remember the details, but it was similar. Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
Hi Jim, On Wed, 3 Oct 2007, Jim Meyering wrote: And yes, I'll of course try a new coreutils/gnulib version (but I think in this case I shouldn't yet). Are there any coreutils snapshot .tar.gz available? Yes. I made a new snapshot just a few hours ago, too: http://meyering.net/cu/coreutils-6.9-ss.tar.gz http://meyering.net/cu/coreutils-6.9-ss.tar.gz.sig I now built the newer snapshot from 2-Oct-2007 and ran the tests. Long Thanks. The three that failed with 'Segmentation fault' look like good candidates to investigate first. Can you debug those? the second and third (they occur when seq is run) are easy to explain, but probably difficult to fix... The Interix libc is built with MSVC. MSVC has no long double data type. Ok, it understands long double, but always maps that to 64-bit double. So libc's printf(), when it sees %Lg, expects 64-bit double. But Interix also has gcc. gcc OTOH has 80 bit long double (stored are 12 bytes). When I build seq with gcc, for the %Lg arg 12 bytes are reserved. This will crash then. I don't know how to fix that... Is there a way to force seq to only use double, no long double? OTOH I plan to eventually port glibc to Interix some (very?) future day, as I also noticed several other problems with Interix's libc. Are there other long double printf usages in coreutils which might be broken on Interix, too? The first 'Segmentation fault' with dd doesn't occur when I run just the failing command in the src dir: ./dd cbs=4 ibs=4 conv=unblock,sync dd-in dd-out dd-out looks fine there. So I don't currently know how to reproduce it... Martin ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
Martin Koeppe [EMAIL PROTECTED] writes: The Interix libc is built with MSVC. MSVC has no long double data type. Ok, it understands long double, but always maps that to 64-bit double. So libc's printf(), when it sees %Lg, expects 64-bit double. But Interix also has gcc. gcc OTOH has 80 bit long double (stored are 12 bytes). When I build seq with gcc, for the %Lg arg 12 bytes are reserved. This will crash then. I don't know how to fix that... The right fix is to use a ABI compatible compiler. If gcc cannot generate code that is compatible with the system library it is a bug that should be reported. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
On Thu, 27 Sep 2007, Jim Meyering wrote: Martin Koeppe [EMAIL PROTECTED] wrote: ... And yes, I'll of course try a new coreutils/gnulib version (but I think in this case I shouldn't yet). Are there any coreutils snapshot .tar.gz available? Yes. I made a new snapshot just a few hours ago, too: http://meyering.net/cu/coreutils-6.9-ss.tar.gz http://meyering.net/cu/coreutils-6.9-ss.tar.gz.sig I now built the newer snapshot from 2-Oct-2007 and ran the tests. Long test output is attached. I killed the last test logged in there with ^C because it has hung for over one hour. With the current Debian snapshot (20070907) the tests run through, however. You can find the build log with the (short) test results for the Debian version at http://www.debian-interix.net/debian-interix/pool/experimental/coreutils/ currently file coreutils_6.10%7e20070907-2+interix.3_20071003-0017.gz Please ignore some of the failing tests, there are some standard problems with interix with file ownership, root user and uid 0. Interix has no user root nor an uid 0. It has user Administrator with uid 197108 which is equivalent to root. I run the tests with that Administrator, so some permission problems are due to the fact that the tests don't expect root rights, but effectively have them. Another issue due to that should be addressed however. I can't run make check-root when I am the equivalent of root, apparently just because of the username or uid. Didn't look into that yet. A question arises: How should one portably test for root? Neither root nor uid 0 seem to be a POSIX requirement. I found one solution so far, but I'm not sure how good it really is: For shell scripts run: $ /usr/sbin/chroot / /bin/true If successful, you have root rights. I'm willing to (re-)run (more) tests, but currently can't say which might be bugs in coreutils and therefore worth investigating and which are only interix specific. Maybe you know better. If necessary, just ask about details on one test or another. Another issue concerning gnulib: Interix has a working getcwd(), but doesn't support auto malloc via getcwd(NULL, 0). The replacement in gnulib seems overkill, however, it's much slower than the original getcwd(). In the Debian build I only added the missing malloc() in xgetcwd() while otherwise using the system getcwd(). (For the patch see file coreutils_6.10%7e20070907-2_6.10%7e20070907-2+interix.3.interdiff.gz in the dir mentioned above.) For the snapshot build I didn't make this modification, so there the gnulib getcwd() is used. I think I found the reason for the Unknown system error in between, too. For that interix seems buggy. You may look at http://www.interopcommunity.com/tm.aspx?m=13238 for details. The workaround I found is to do a chdir(getcwd()) at the beginning of all coreutils binaries, just using initialize_main() for that. This shouldn't added to official coreutils yet, I think. OTOH, It worked without that patch in coreutils 5.97. Martin makecheck.log.gz Description: Binary data ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
Martin Koeppe [EMAIL PROTECTED] wrote: On Thu, 27 Sep 2007, Jim Meyering wrote: Martin Koeppe [EMAIL PROTECTED] wrote: ... And yes, I'll of course try a new coreutils/gnulib version (but I think in this case I shouldn't yet). Are there any coreutils snapshot .tar.gz available? Yes. I made a new snapshot just a few hours ago, too: http://meyering.net/cu/coreutils-6.9-ss.tar.gz http://meyering.net/cu/coreutils-6.9-ss.tar.gz.sig I now built the newer snapshot from 2-Oct-2007 and ran the tests. Long Thanks. The three that failed with 'Segmentation fault' look like good candidates to investigate first. Can you debug those? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
Martin Koeppe [EMAIL PROTECTED] wrote: A question arises: How should one portably test for root? Neither root nor uid 0 seem to be a POSIX requirement. I found one solution so far, but I'm not sure how good it really is: For shell scripts run: $ /usr/sbin/chroot / /bin/true If successful, you have root rights. I'm leery of this. What if chroot works for non-privileged users on some type of system? Since Interix is the problem here, how about adding a test that'd be run solely on that system? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
On Wed, 3 Oct 2007, Jim Meyering wrote: Martin Koeppe [EMAIL PROTECTED] wrote: A question arises: How should one portably test for root? Neither root nor uid 0 seem to be a POSIX requirement. I found one solution so far, but I'm not sure how good it really is: For shell scripts run: $ /usr/sbin/chroot / /bin/true If successful, you have root rights. I'm leery of this. What if chroot works for non-privileged users on some type of system? Since Interix is the problem here, how about adding a test that'd be run solely on that system? Yes, no problem with that. I only thought there might be a possibility to check the root-ness without an explicit comparison of uid or username. This need not necessarily be the chroot() function. But I don't know the POSIX standard in that detail. If you want an explicit check, then for Interix 3 different users/uids must be checked: System (uid ???), Domain Administrator (uid 1049076) and local Administrator (uid 197108). All of these have root rights. See: http://www.interopcommunity.com/faqs.aspx#307 Martin ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
John Cowan [EMAIL PROTECTED] wrote: Jim Meyering scripsit: What if chroot works for non-privileged users on some type of system? That sounds extremely unlikely, [...] It's not so far-fetched. There's a hint on the first lines of info coreutils chroot: `chroot' runs a command with a specified root directory. On many systems, only the super-user can do this. Synopses: I wrote many rather than all for a good reason. A quick search shows there is at least one exception: http://lists.freebsd.org/pipermail/freebsd-security/2003-April/000125.html ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
Martin Koeppe [EMAIL PROTECTED] wrote: On Wed, 3 Oct 2007, Jim Meyering wrote: Martin Koeppe [EMAIL PROTECTED] wrote: A question arises: How should one portably test for root? Neither root nor uid 0 seem to be a POSIX requirement. I found one solution so far, but I'm not sure how good it really is: For shell scripts run: $ /usr/sbin/chroot / /bin/true If successful, you have root rights. I'm leery of this. What if chroot works for non-privileged users on some type of system? Since Interix is the problem here, how about adding a test that'd be run solely on that system? Yes, no problem with that. I only thought there might be a possibility to check the root-ness without an explicit comparison of uid or username. This need not necessarily be the chroot() function. But I don't know the POSIX standard in that detail. If you want an explicit check, then for Interix 3 different users/uids must be checked: System (uid ???), Domain Administrator (uid 1049076) and local Administrator (uid 197108). All of these have root rights. See: http://www.interopcommunity.com/faqs.aspx#307 But those are all legitimate, non-root IDs on other systems, so a test based solely on that would risk false positives. There has to be something else (interix-specific) that will ensure that part of the test is run only on Interix. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: Re: error.c: Unknown system error should report errno value
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/3/2007 8:26 AM: I'm leery of this. What if chroot works for non-privileged users on some type of system? It works for all users on cygwin (seeing as how chroot isn't natively provided by Windows, cygwin has no ability to add any security added by using chroot in the first place, so it just provides a pseudo-chroot regardless of uid). - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHBDtr84KuGfSFAYARAs+sAJ0bxX3Q3gyVvohazrlTfqvXFgZTSACgrLtL sNSBDezpHcMjcWxaTuyJEjM= =LCl7 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: error.c: Unknown system error should report errno value
Martin Koeppe [EMAIL PROTECTED] writes: + s = _(Unknown system error); + fprintf (stderr, : %s (errno=%d), s, errnum); I like the idea, but that errno= grates a bit, as user diagnostics shouldn't be so low-level. How about this instead? fprintf (stderr, _(: Unknown system error number %d), errnum); ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: error.c: Unknown system error should report errno value
On Mon, 24 Sep 2007, Paul Eggert wrote: Martin Koeppe [EMAIL PROTECTED] writes: + s = _(Unknown system error); + fprintf (stderr, : %s (errno=%d), s, errnum); I like the idea, but that errno= grates a bit, as user diagnostics shouldn't be so low-level. How about this instead? fprintf (stderr, _(: Unknown system error number %d), errnum); Ok, I could live with that. My idea was not to change the original string to avoid re-translation and to give a clear hint what this number is meant to be, i.e. that's an errno value. The number alone is probably of no use to any normal user anyway. (Though I first had only (%d) myself.) OTOH if strerror() cannot resolve the errno value, then there is probably a bigger problem in it, not a normally occuring case (generating a user level diagnostic has just failed!), and debugging should be made easy. I also think it's a good idea to have : and %d not within the string for easy and uniform translations. That's probably why %s is used that often I could imagine. But with your idea in a debug case one could grep through all the source files and would also find that it is an errno value which has been reported. So I'm not against your idea. Martin ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: error.c: Unknown system error should report errno value
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [adding gnulib, as this problem is really a gnulib one, not a coreutils] According to Martin Koeppe on 9/24/2007 5:46 PM: On Mon, 24 Sep 2007, Paul Eggert wrote: Martin Koeppe [EMAIL PROTECTED] writes: + s = _(Unknown system error); + fprintf (stderr, : %s (errno=%d), s, errnum); I like the idea, but that errno= grates a bit, as user diagnostics shouldn't be so low-level. How about this instead? fprintf (stderr, _(: Unknown system error number %d), errnum); Ok, I could live with that. My idea was not to change the original string to avoid re-translation and to give a clear hint what this number is meant to be, i.e. that's an errno value. The number alone is probably of no use to any normal user anyway. (Though I first had only (%d) myself.) The Austin group debated making the next version of POSIX required to always return a non-NULL result for strerror (although for out-of-range errors, there was no guarantee that the string had to be unique, as in printing what the out-of-range value was). However, I think that proposal has stalled, so the Interix behavior of returning NULL for strerror(-1) is not yet non-POSIX compliant. I am very much in favor of a gnulib implementation of strerror that works harder to provide non-NULL results. OTOH if strerror() cannot resolve the errno value, then there is probably a bigger problem in it, not a normally occuring case (generating a user level diagnostic has just failed!), and debugging should be made easy. I also think it's a good idea to have : and %d not within the string for easy and uniform translations. Actually, gettext encourages putting %d in the translation, so that languages that use pluralization rules in their translation can deal with it better. In other words, Paul's suggested wording is better. For reference, here's what cygwin does with unknown errors: Unknown error %u without translation (but then again, cygwin lacks builtin translation). - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+IJ284KuGfSFAYARAqfAAJ9qulY2G/MT6OaTYAIi0lxU/qFSuACZAZz0 H3Q0B0nThfZQHDJ5Zpywu0Y= =Idym -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
