bug#13516: tests/rm/unread3 fails on Mac OS X 10.8
On 1/27/13 8:34 PM, Paul Eggert wrote: Thanks, can you please try this patch instead? It's a bit more drastic, but I hope it fixes the loop without introducing that other bug. Thank you. Your patch does the trick on OS X 10.8.2, however, it causes test-getcwd.sh to fail now. Global Odey FAIL: test-getcwd.sh ++ initial_cwd_=/var/ac/bld/coreutils-8.20.103-bb116/gnulib-tests ++ fail=0 +++ testdir_prefix_ +++ printf gt ++ pfx_=gt +++ mktempd_ /var/ac/bld/coreutils-8.20.103-bb116/gnulib-tests gt-test-getcwd.sh. +++ case $# in +++ destdir_=/var/ac/bld/coreutils-8.20.103-bb116/gnulib-tests +++ template_=gt-test-getcwd.sh. +++ MAX_TRIES_=4 +++ case $destdir_ in +++ case $template_ in unset TMPDIR +++ d='/tmp/-p.sDffDhsB gt-test-getcwd.sh.DI26' +++ fail=1 +++ case $d in +++ fail=1 +++ test -d '/tmp/-p.sDffDhsB gt-test-getcwd.sh.DI26' +++ fail=1 ls -dgo '/tmp/-p.sDffDhsB gt-test-getcwd.sh.DI26' tr S - +++ perms= +++ case $perms in +++ fail=1 +++ test 1 = 0 echo gt-test-getcwd.sh. sed 's/XX*$//' +++ base_template_=gt-test-getcwd.sh. echo gt-test-getcwd.sh. wc -c +++ template_length_=' 23' echo gt-test-getcwd.sh. wc -c +++ nx_=' 19' expr 23 - 19 +++ nx_=4 +++ err_= +++ i_=1 +++ : rand_bytes_ 4 n_=4 chars_=abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 dev_rand_=/dev/urandom test -r /dev/urandom dd ibs=4 count=1 if=/dev/urandom LC_ALL=C tr -c abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 01234567abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 return +++ X_=Bv7A +++ candidate_dir_=/var/ac/bld/coreutils-8.20.103-bb116/gnulib-tests/gt-test-getcwd.sh.Bv7A mkdir -m 0700 /var/ac/bld/coreutils-8.20.103-bb116/gnulib-tests/gt-test-getcwd.sh.Bv7A +++ err_= +++ echo /var/ac/bld/coreutils-8.20.103-bb116/gnulib-tests/gt-test-getcwd.sh.Bv7A +++ return ++ test_dir_=/var/ac/bld/coreutils-8.20.103-bb116/gnulib-tests/gt-test-getcwd.sh.Bv7A ++ cd /var/ac/bld/coreutils-8.20.103-bb116/gnulib-tests/gt-test-getcwd.sh.Bv7A ++ gl_init_sh_nl_=' ' ++ IFS=' ' ++ for sig_ in 1 2 3 13 15 +++ expr 1 + 128 ++ eval 'trap '\''Exit 129'\'' 1' +++ trap 'Exit 129' 1 ++ for sig_ in 1 2 3 13 15 +++ expr 2 + 128 ++ eval 'trap '\''Exit 130'\'' 2' +++ trap 'Exit 130' 2 ++ for sig_ in 1 2 3 13 15 +++ expr 3 + 128 ++ eval 'trap '\''Exit 131'\'' 3' +++ trap 'Exit 131' 3 ++ for sig_ in 1 2 3 13 15 +++ expr 13 + 128 ++ eval 'trap '\''Exit 141'\'' 13' +++ trap 'Exit 141' 13 ++ for sig_ in 1 2 3 13 15 +++ expr 15 + 128 ++ eval 'trap '\''Exit 143'\'' 15' +++ trap 'Exit 143' 15 ++ trap remove_tmp_ 0 + path_prepend_ . + test 1 '!=' 0 + path_dir_=. + case $path_dir_ in + abs_path_dir_=/var/ac/bld/coreutils-8.20.103-bb116/gnulib-tests/. + case $abs_path_dir_ in + PATH=/var/ac/bld/coreutils-8.20.103-bb116/gnulib-tests/.:/usr/local/llvm-3.2/bin:/usr/local/bin:/usr/local/stage1/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin + create_exe_shims_ /var/ac/bld/coreutils-8.20.103-bb116/gnulib-tests/. + case $EXEEXT in + return 0 + shift + test 0 '!=' 0 + export PATH + test-getcwd + Exit 47 + set +e + exit 47 + exit 47 + remove_tmp_ + __st=47 + cleanup_ + : + cd /var/ac/bld/coreutils-8.20.103-bb116/gnulib-tests + chmod -R u+rwx /var/ac/bld/coreutils-8.20.103-bb116/gnulib-tests/gt-test-getcwd.sh.Bv7A + rm -rf /var/ac/bld/coreutils-8.20.103-bb116/gnulib-tests/gt-test-getcwd.sh.Bv7A + exit 47 Testsuite summary for GNU coreutils 8.20.103-bb116 # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See gnulib-tests/test-suite.log Please report to bug-coreutils@gnu.org
bug#13516: tests/rm/unread3 fails on Mac OS X 10.8
On 1/28/13 6:47 PM, Paul Eggert wrote: OK, how about the attached patch instead? After correcting a minor issue (*/tests/test-getcwd.c needed to be changed to */gnulib-tests/test-getcwd.c in the last patch), tests/rm/unread3.sh continues to pass while gnulib-tests/test-getcwd.sh still fails. Thanks Global Odey ++ initial_cwd_=/var/ac/bld/coreutils-8.20.104-f2551/gnulib-tests ++ fail=0 +++ testdir_prefix_ +++ printf gt ++ pfx_=gt +++ mktempd_ /var/ac/bld/coreutils-8.20.104-f2551/gnulib-tests gt-test-getcwd.sh. +++ case $# in +++ destdir_=/var/ac/bld/coreutils-8.20.104-f2551/gnulib-tests +++ template_=gt-test-getcwd.sh. +++ MAX_TRIES_=4 +++ case $destdir_ in +++ case $template_ in unset TMPDIR +++ d='/tmp/-p.lC7r3rZe gt-test-getcwd.sh.DvFF' +++ fail=1 +++ case $d in +++ fail=1 +++ test -d '/tmp/-p.lC7r3rZe gt-test-getcwd.sh.DvFF' +++ fail=1 ls -dgo '/tmp/-p.lC7r3rZe gt-test-getcwd.sh.DvFF' tr S - +++ perms= +++ case $perms in +++ fail=1 +++ test 1 = 0 echo gt-test-getcwd.sh. sed 's/XX*$//' +++ base_template_=gt-test-getcwd.sh. echo gt-test-getcwd.sh. wc -c +++ template_length_=' 23' echo gt-test-getcwd.sh. wc -c +++ nx_=' 19' expr 23 - 19 +++ nx_=4 +++ err_= +++ i_=1 +++ : rand_bytes_ 4 n_=4 chars_=abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 dev_rand_=/dev/urandom test -r /dev/urandom dd ibs=4 count=1 if=/dev/urandom LC_ALL=C tr -c abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 01234567abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 return +++ X_=l0KN +++ candidate_dir_=/var/ac/bld/coreutils-8.20.104-f2551/gnulib-tests/gt-test-getcwd.sh.l0KN mkdir -m 0700 /var/ac/bld/coreutils-8.20.104-f2551/gnulib-tests/gt-test-getcwd.sh.l0KN +++ err_= +++ echo /var/ac/bld/coreutils-8.20.104-f2551/gnulib-tests/gt-test-getcwd.sh.l0KN +++ return ++ test_dir_=/var/ac/bld/coreutils-8.20.104-f2551/gnulib-tests/gt-test-getcwd.sh.l0KN ++ cd /var/ac/bld/coreutils-8.20.104-f2551/gnulib-tests/gt-test-getcwd.sh.l0KN ++ gl_init_sh_nl_=' ' ++ IFS=' ' ++ for sig_ in 1 2 3 13 15 +++ expr 1 + 128 ++ eval 'trap '\''Exit 129'\'' 1' +++ trap 'Exit 129' 1 ++ for sig_ in 1 2 3 13 15 +++ expr 2 + 128 ++ eval 'trap '\''Exit 130'\'' 2' +++ trap 'Exit 130' 2 ++ for sig_ in 1 2 3 13 15 +++ expr 3 + 128 ++ eval 'trap '\''Exit 131'\'' 3' +++ trap 'Exit 131' 3 ++ for sig_ in 1 2 3 13 15 +++ expr 13 + 128 ++ eval 'trap '\''Exit 141'\'' 13' +++ trap 'Exit 141' 13 ++ for sig_ in 1 2 3 13 15 +++ expr 15 + 128 ++ eval 'trap '\''Exit 143'\'' 15' +++ trap 'Exit 143' 15 ++ trap remove_tmp_ 0 + path_prepend_ . + test 1 '!=' 0 + path_dir_=. + case $path_dir_ in + abs_path_dir_=/var/ac/bld/coreutils-8.20.104-f2551/gnulib-tests/. + case $abs_path_dir_ in + PATH=/var/ac/bld/coreutils-8.20.104-f2551/gnulib-tests/.:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin + create_exe_shims_ /var/ac/bld/coreutils-8.20.104-f2551/gnulib-tests/. + case $EXEEXT in + return 0 + shift + test 0 '!=' 0 + export PATH + test-getcwd + Exit 7 + set +e + exit 7 + exit 7 + remove_tmp_ + __st=7 + cleanup_ + : + cd /var/ac/bld/coreutils-8.20.104-f2551/gnulib-tests + chmod -R u+rwx /var/ac/bld/coreutils-8.20.104-f2551/gnulib-tests/gt-test-getcwd.sh.l0KN + rm -rf /var/ac/bld/coreutils-8.20.104-f2551/gnulib-tests/gt-test-getcwd.sh.l0KN + exit 7
bug#13516: tests/rm/unread3 fails on Mac OS X 10.8
On 1/30/13 1:25 AM, Paul Eggert wrote: Can you use GDB to debug the situation? No. That is, I'm willing but apparently not able. Try running something like this: gdb test-getcwd b getcwd r fin p errno GDB didn't seem to offer up much. It was able to find getcwd (after loading shared libraries) and set the breakpoint but it would exit out (still with error code 7) before reaching the break. After looking through test-getcwd.c, though, I don't know how that's possible. I can say for sure that when GDB was setting the breakpoint, it was finding libc's getcwd, not GNUlib's (based on its address). That sort of thing. Hopefully, this qualifies: Because I was unable to get anything else out of GDB (that was literally my first time ever using the program), I resorted to directly editing test-getcwd.c a few times and determined that errno gets set to ENOENT before triggering the failure. Global Odey
bug#13516: tests/rm/unread3 fails on Mac OS X 10.8
On 1/30/13 7:19 PM, Paul Eggert wrote:
What happens if you put a breakpoint on rpl_getcwd instead? Use "b rpl_getcwd".
That should get Gnulib's getcwd instead of libc's.
Okay that certainly got me on the right track. I tried a lot of
different things without finding the exact cause of the error so I'll
pass on a few things that stood out to me and maybe that will help make
more sense out of things on your end.
Ultimately, I used a breakpoint at line 196 of test-getcwd.c (see below)
quite a bit.
192 if (dotdot_max <= cwd_len - initial_cwd_len)
193{
194 if (dotdot_max + DIR_NAME_SIZE < cwd_len - initial_cwd_len)
195break;
-> 196 c = getcwd (buf, cwd_len + 1);
197 if (!c)
198{
199 if (! (errno == ERANGE || errno == ENOENT
The main reason was that I very quickly got lost trying follow getcwd
(in getcwd.c) so I tried to stop things right before getcwd was called
and that's when a few interesting things showed up. To start with, the
value of buf was always 1023 characters long despite the array having a
size of 4125. I don't know if it's related but it stands out to me that
PATH_MAX is set to 1024. The way the path was made to always be 1023
characters was interesting, too. Rather than truncating the very end of
the path, it would start by truncating the name of the first directory
and then go on to the next one if the name of the first directory wasn't
long enough. So what should have been
"/reallylongdirectoryname/confdir3.../confdir3" would end up as
"/reallylongdire/confdir3.../confdir3" and
"/a/b/c/d/e/f/g/h/i/j/confdir3.../confdir3" became
"//d/e/f/g/h/i/j/confdir3.../confdir3".
Looking at some of the other variables only brought more confusion.
cwd_len (getcwd's second argument on line 196) turned out to have the
same value as initial_cwd_len so I don't know what line 160 was doing. I
was expecting cwd_len to be at least 1023 to match buf. Trying to figure
out how the program even got to this point, I checked the value of
dotdot_max (used on line 192) which should have been 3072 and instead it
was 0. The values of dotdot_max and cwd_len both depend on
DIR_NAME_SIZE. Is this being unset by another function? It's definitely
defined above (line 116) and successfully used in setting the array size
of buf (line 141).
On another note, I've actually gotten to the bottom of a few, ancillary
things:
First, I was wrong on my assumptions of what Darwin is and is not. Even
though eg. Google's autocomplete seems to think "Darwin kernel" is a
legitimate phrase, according to Wikipedia, Darwin is the Unix-based OS
that OS X (also an OS) is built upon. The kernel is called XNU and is a
combination of the Mach and FreeBSD kernels which is why you'll often
see it referenced as simply the Mach kernel. To me, this makes OS X look
more like a distro where instead of being built on top of GNU/Linux with
a Linux kernel, it's built on top of Darwin with an XNU kernel. My
points on versioning between OS X and Darwin and the ridiculousness of
that FAQ still stand, though.
Paul, earlier in this thread you asked why Apple hadn't yet implemented
fdopendir. My best guess is that Apple will have it implemented the day
The Open Group settles on a UNIX 1x specification. Apple claims (and is
certified for) 100% conformance to UNIX 03 which is based on SUS 3 /
POSIX.1-2001. Even though there is a SUS 4 / POSIX.1-2008, there doesn't
seem to be any corresponding UNIX branding so, hopefully, as soon as The
Open Group figures out how they want to certify compliance (and how much
they want to charge), there will be an fdopendir in the following
release of OS X. Also, if you don't already know about it,
opensource.apple.com has a ton of information on mostly Darwin including
all of the (open) source code for every version of OS X.
Assaf, you might give LLDB (the debugger for LLVM/Clang) a try. Apple's
version of GDB is about 8 years old now. I tried the latest version of
GDB (even with the latest GCC) and, suffice to say, it is utterly broken
on OS X. Still, wanting something newer, I tried LLDB using this guide
here for reference and it seemed to work
pretty well (but then again, I don't really know what I'm doing so ymmv).
Global Odey
