bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#13516: tests/rm/unread3 fails on Mac OS X 10.8


From: Global Odey
Subject: Re: bug#13516: tests/rm/unread3 fails on Mac OS X 10.8
Date: Fri, 01 Feb 2013 19:40:02 -0600
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Thunderbird/20.0a2

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)
   195            break;
-> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]