make check log for Interix
Hi all, I've built the coreutils snapshot 354 and run make check. seq is ok now, thanks. The full results are attached. Martin make-check.log.gz Description: Binary data ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new coreutils snapshot
Hi Paul, On Wed, 24 Oct 2007, Paul Eggert wrote: Martin Koeppe [EMAIL PROTECTED] writes: Ok, download is possible now. But seq is still wrong for me. Either include the gnulib printf-posix module, or change seq to use asprintf() instead of printf() to fix. See the previous mails on that by Bruno and me. Can you please clarify? What I see from previous emails is this: http://lists.gnu.org/archive/html/bug-coreutils/2007-10/msg00121.html This refers to some private correspondence, but it's not exactly clear to me what the bug is, or why adding printf-posix will fix it. Ordinarily we'd rather use printf than using aprintf and then sending the result to stdout; that way we don't need to worry about memory-allocation issues. seq uses long double output, which doesn't work on some platforms. So it's necessary to use a replacement *printf() on these. The relevant functions are asprintf() and printf(). As seq uses asprintf() anyway, one could replace printf() with asprintf() and have only asprintf() to replace on these long double failing systems, but I see the malloc() disadvantage. This has been discussed here, and as a result of the discussion the vasprintf-posix module has been added, which was insufficient however: http://lists.gnu.org/archive/html/bug-coreutils/2007-10/msg00033.html http://lists.gnu.org/archive/html/bug-coreutils/2007-10/msg00068.html http://lists.gnu.org/archive/html/bug-gnulib/2007-10/msg00082.html http://lists.gnu.org/archive/html/bug-gnulib/2007-10/msg00083.html http://lists.gnu.org/archive/html/bug-gnulib/2007-10/msg00084.html http://lists.gnu.org/archive/html/bug-gnulib/2007-10/msg00121.html http://lists.gnu.org/archive/html/bug-gnulib/2007-10/msg00122.html http://lists.gnu.org/archive/html/bug-gnulib/2007-10/msg00123.html http://lists.gnu.org/archive/html/bug-gnulib/2007-10/msg00124.html http://lists.gnu.org/archive/html/bug-coreutils/2007-10/msg00121.html http://lists.gnu.org/archive/html/bug-coreutils/2007-10/msg00122.html http://lists.gnu.org/archive/html/bug-coreutils/2007-10/msg00123.html Unfortunately, the thread had several topics, as they all came up when I tried to build coreutils on Interix. In the listing above, I only mentioned the mails relevant to seq, however. Martin ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new coreutils snapshot
Hi Jim, 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. I just wanted to download the new snapshot to make sure seq now works for me, before the release. Unfortunately, I get 403 Permission denied on both http://meyering.net/cu/coreutils-6.9-340-def15.tar.gz http://meyering.net/cu/ Martin ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new coreutils snapshot
On Wed, 24 Oct 2007, Jim Meyering wrote: Martin Koeppe [EMAIL PROTECTED] wrote: I just wanted to download the new snapshot to make sure seq now works for me, before the release. Unfortunately, I get 403 Permission denied on both http://meyering.net/cu/coreutils-6.9-340-def15.tar.gz http://meyering.net/cu/ Hi Martin, Thanks for letting me know. It's fixed now. Ok, download is possible now. But seq is still wrong for me. Either include the gnulib printf-posix module, or change seq to use asprintf() instead of printf() to fix. See the previous mails on that by Bruno and me. Thanks 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
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
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: 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)
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
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
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
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
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
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
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
error.c: Unknown system error should report errno value
Hi all,
please consider printing the errno value together with Unknown system
error if strerror() failed. It failed for me on Interix for
errno=-1, which I'm interested to know about, just to get an idea what
could be wrong, and that strerror() is not wrong.
Martin--- gnulib/lib/error.c.orig Sat Jul 21 10:10:38 2007
+++ gnulib/lib/error.c Mon Sep 24 20:38:36 2007
@@ -121,15 +121,16 @@
s = strerror (errnum);
#endif
-#if !_LIBC
- if (! s)
-s = _(Unknown system error);
-#endif
-
#if _LIBC
__fxprintf (NULL, : %s, s);
#else
- fprintf (stderr, : %s, s);
+ if (s)
+fprintf (stderr, : %s, s);
+ else
+{
+ s = _(Unknown system error);
+ fprintf (stderr, : %s (errno=%d), s, errnum);
+}
#endif
}
___
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: coreutils on interix: mods to savewd.c and who.c
On Sun, 16 Sep 2007, Martin Koeppe wrote: Hi all, I just tried to build coreutils (6.10pre20070907 from Debian) on interix. The next thing is savewd.c, which requires errno value ESTALE to be there, but interix doesn't have that one. The third is who.c, which doesn't check for IPV6 (interix doesn't have IPV6). For these you'll find a patch attached. Sorry for the fix to who.c. The change needs to be made to a Debian specific addition. Martin ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils on interix: mods to savewd.c and who.c
Hi all,
I just tried to build coreutils (6.10pre20070907 from Debian) on
interix.
The first thing I encountered is the cannot read mounted file
systems issue. I changed configure.ac to only warn about that.
Nevertheless, compilation of df.c was automatically disabled, so
apparently coreutils can handle this already.
The next thing is savewd.c, which requires errno value ESTALE to be
there, but interix doesn't have that one. The third is who.c, which
doesn't check for IPV6 (interix doesn't have IPV6). For these you'll
find a patch attached.
Another issue: I first tried to configure with
--enable-no-install-program=who, but nevertheless who.c is tried to be
built. Shouldn't --enable-no-install-program also disable compilation
of who.c? One might try to disable it, because it doesn't build :-)
After these patches the build went through, but make check doesn't:
Making check in man
make[2]: Entering directory `/tmp/coreutils-6.10~20070907/man'
/usr/bin/make check-local
make[3]: Entering directory `/tmp/coreutils-6.10~20070907/man'
PATH=../src:$PATH; export PATH; \
t=ls-files.$$; \
(cd . ls -1 *.x) | sed 's/\.x$//' | LC_ALL=C sort $t;\
(echo groups.1 uname.1 chroot.1 nice.1 who.1 users.1 [... 8]
| tr -s ' ' '\n' | sed 's/\.1$//') \
| LC_ALL=C sort -u | diff - $t || { rm $t; exit 1; }; \
rm $t
16a17
df
30a32
hostid
make[3]: *** [check-x-vs-1] Error 1
df.c and hostid.c weren't tried to compile. I didn't look into the
details of this one, but simply disabled the whole check for now.
Martin--- coreutils-6.10~20070907/gnulib/m4/ls-mntd-fs.m4.origSun Sep 24
08:49:03 2006
+++ coreutils-6.10~20070907/gnulib/m4/ls-mntd-fs.m4 Sat Sep 15 20:58:50 2007
@@ -327,7 +327,7 @@
fi
if test -z $ac_list_mounted_fs; then
- AC_MSG_ERROR([could not determine how to read list of mounted file systems])
+ AC_MSG_WARN([could not determine how to read list of mounted file systems])
# FIXME -- no need to abort building the whole package
# Can't build mountlist.c or anything that needs its functions
fi
--- coreutils-6.10~20070907/gnulib/lib/savewd.c.origWed Mar 21 09:07:20 2007
+++ coreutils-6.10~20070907/gnulib/lib/savewd.c Sat Sep 15 22:10:47 2007
@@ -54,7 +54,11 @@
wd-val.fd = fd;
break;
}
- if (errno != EACCES errno != ESTALE)
+ if (errno != EACCES
+#ifndef __INTERIX
+ errno != ESTALE
+#endif
+ )
{
wd-state = ERROR_STATE;
wd-val.errnum = errno;
--- coreutils-6.10~20070907/src/who.c.orig Sat Sep 15 23:02:44 2007
+++ coreutils-6.10~20070907/src/who.c Sat Sep 15 23:38:16 2007
@@ -424,6 +424,7 @@
}
#endif
+#if HAVE_IPV6
/* Needs configure check for ut_addr_v6, etc */
if (do_ips
memcmp(utmp_ent-ut_addr_v6, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0, 16))
@@ -474,6 +475,7 @@
getnameinfo(sa, salen, hoststr, 256, NULL, 0, flags);
}
+#endif
print_line (sizeof UT_USER (utmp_ent), UT_USER (utmp_ent), mesg,
sizeof utmp_ent-ut_line, utmp_ent-ut_line,
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
