Re: Dawrin- why does pinky SIGBUS
mwoehlke [EMAIL PROTECTED] writes:
#0 0x90007260 in strlen ()
#1 0x9000d1d8 in strdup ()
#2 0x393c in canon_host_r (host=0xfffc Address 0xfffc
out of bounds, cherror=0x8248) at canon-host.c:74
This suggest that this code in canon-host.c:
hints.ai_flags = AI_CANONNAME;
status = getaddrinfo (host, NULL, hints, res);
if (!status)
{
retval = strdup (res-ai_canonname);
set status to 0, but res-ai_canonname was NULL. Can you verify
that this in fact happened?
Are you using the system getaddrinfo, or the one shipped with
coreutils?
Honestly I have never used pinky so I don't really care.
It's a sign of problems in the library, though. It should
get fixed.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Darwin - chmod broken?
mwoehlke [EMAIL PROTECTED] writes: You are looking for this, yes? Yes, that sort of thing. 10487 chmodCALL chmod(0x2800600,0x1a4) 10487 chmodNAMI . 10487 chmodRET chmod 0 10487 chmodCALL chmod(0x2800600,0x1a4) 10487 chmodNAMI b 10487 chmodRET chmod 0 10487 chmodCALL close(0x1) 10487 chmodRET close 0 10487 chmodCALL exit(0) Does that look right? No. It looks like your kernel is busted. The first chmod sets the permissions of . to 644, i.e., nobody can search it. But the second chmod searches . successfully. Are you running this test as root? If I am reading 'man 2 chmod' right, the second chmod() is expected to fail with EACCES? Yes, that's right. It looks like your operating system is buggy. Can you reproduce this bug with /bin/chmod? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Darwin HFS+ bug
[EMAIL PROTECTED] writes: Does the new coreutils+gnulib call sync(2) at appropriate places? coreutils calls 'sync' only in the 'sync' and 'shred' and 'df --sync' commands, which are irrelevant here. Applications should never have to call 'sync' to do ordinary things like remove files, so I don't know what you mean by appropriate places. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Darwin HFS+ bug
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: CONSECUTIVE_READDIR_UNLINK_THRESHOLD = 200 I looked into this a bit, and found myself wondering: why does 'rm' need to have this constant? Could rm do the rough equivalent of savedir on the directory (copying its file names and perhaps types into main memory), and then walk through the in-memory copy of the directory? Such an approach would take more memory, but the extra memory should be acceptable these days. Also, this approach would walk through the directory twice, but in the normal case this wouldn't hurt performance much, and it might even help performance. An advantage of this approach is that we wouldn't need these fudge factors for buggy file systems. I wrote a prototype savedir-based implementation from scratch. It is a more efficient when there are many directories containing many entries, but it demonstrates O(n^2) performance when the hierarchy is deep and narrow, e.g., /x/x/x/x/x/x/.../x. So, yes, this is worth investigating. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort 5.97 bug sorting a month embedded in a field
Gordon Grimes [EMAIL PROTECTED] writes: (I have 18 years experience with 'sort') [529] cat dates 142 01-APR-2006 16 01-DEC-2005 31 01-FEB-2006 13 01-JAN-2006 55 01-MAR-2006 13312 01-MAY-2006 1 01-NOV-2005 1 01-OCT-2005 145 02-APR-2006 13 02-DEC-2005 [533] cat may_dates | sort -k2.4,2.6M ## should work sort --help says If neither the -t nor the -b option is in effect, the characters in a field are counted from the beginning of the preceding whitespace. That's what's happening here. So you want sort -k2.5,2.7M, to take that white space into account. There's no bug. (Now you have 18 years plus 1 day experience with 'sort'. :-) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: printf bug/limitation
Singh, Sundeep wrote: Hi, I have a printf statement in my script as follows: printf -- %s \n $name Pass -- first to printf to tell it you're not passing it any (more) command line options, like: printf -- -- %s \n $name Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort 5.97 bug sorting a month embedded in a field
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Gordon Grimes on 9/26/2006 9:52 PM: Eric, I don't see it set in the cygwin environment. Why didn't you mention your platform in the first case? Cygwin lacks locales (thanks to its use of newlib, which is currently hardcoded to the C locale), so not setting LC_ALL won't really make much of a difference there. Can you get it to work with embedded values? Yes, see Paul's mail, or experiment with -b. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFGnAg84KuGfSFAYARAmbiAKDAOMgAtwSr6fytdQCb5v0SGg0ENwCeN0Vv Xj2AowrqghbGm0P4aMmXUAQ= =GkF2 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-gnulib] Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)
Jim Meyering wrote:
I'll use 180.
The lower we go, the more of a performance penalty
we impose for directories with very many entries.
I tried the value 180. It worked fine in some cases, but still failed in
others:
$ tar xf /Volumes/ExtData/bin.x86-linux/cross/cross-hppa.tar.gz
$ ll cross/hppa-linux/share/i18n/charmaps | wc -l
195
$ rm -r cross
rm: Entfernen von Verzeichnis „cross/hppa-linux/share/i18n/charmaps“ nicht
möglich: Directory not empty
$ ll cross/hppa-linux/share/i18n/charmaps | wc -l
17
$ rm -r cross
Actually the number of files that can be removed before stumbling on the
bug depends on the length of the filenames. Here it a command that
generates a table. First column: l, the length of an additional suffix tacked
on every filename. Second column: n, the number of files that can be removed
without hitting the bug.
$ for l in `seq 0 200`; do
suffix=`printf %${l}s | tr ' ' 'S'`;
tar xf /Volumes/ExtData/bin.x86-linux/cross/cross-hppa.tar.gz;
if test $l != 0; then
(cd cross/hppa-linux/share/i18n/charmaps;
for f in *; do mv $f $f$suffix; done
);
fi;
before=`ls -l cross/hppa-linux/share/i18n/charmaps | wc -l`;
rm -rf cross 2/dev/null;
after=`ls -l cross/hppa-linux/share/i18n/charmaps | wc -l`;
removed=`expr $before - $after`;
while ! rm -rf cross 2/dev/null ; do : ; done;
printf '%3d %3d\n' $l $removed;
done
l n
--- ---
0 178
1 174
2 170
3 156
4 152
5 150
6 148
7 138
8 135
9 134
10 131
11 122
12 120
13 119
14 117
15 109
16 108
17 107
18 105
19 99
20 97
21 96
22 95
23 90
24 88
25 87
26 86
27 82
28 115
29 80
30 79
31 76
32 75
33 74
34 73
35 70
36 69
37 69
38 67
39 66
40 65
41 64
42 63
43 61
44 60
45 60
46 59
47 58
48 57
49 57
50 56
51 55
52 54
53 54
54 53
55 52
56 51
57 51
58 50
59 49
60 49
61 48
62 48
63 47
64 46
65 46
66 46
67 45
68 44
69 44
70 43
71 43
72 85
73 42
74 42
75 41
76 41
77 40
78 40
79 39
80 39
81 39
82 38
83 38
84 38
85 37
86 37
87 36
88 36
89 36
90 36
91 35
92 35
93 35
94 35
95 34
96 34
97 34
98 68
99 33
100 33
101 33
102 32
103 32
104 32
105 32
106 31
107 31
108 31
109 31
110 30
111 30
112 30
113 30
114 30
115 29
116 29
117 29
118 29
119 28
120 28
121 28
122 28
123 28
124 27
125 27
126 27
127 27
128 27
129 27
130 26
131 26
132 26
133 26
134 26
135 25
136 25
137 25
138 25
139 25
140 25
141 25
142 24
143 24
144 24
145 24
146 24
147 24
148 23
149 23
150 23
151 23
152 23
153 23
154 23
155 22
156 22
157 22
158 22
159 22
160 22
161 22
162 22
163 22
164 21
165 21
166 21
167 21
168 21
169 21
170 21
171 21
172 21
173 20
174 20
175 20
176 20
177 20
178 20
179 20
180 20
181 20
182 20
183 19
184 19
185 19
186 19
187 19
188 19
189 19
190 19
191 19
192 19
193 19
194 19
195 18
196 18
197 18
198 18
199 18
200 18
The initial directory contents is:
3 files of length 5
4 files of length 6
3 files of length 7
6 files of length 8
64 files of length 9
10 files of length 10
8 files of length 11
21 files of length 12
18 files of length 13
13 files of length 14
9 files of length 15
12 files of length 16
6 files of length 17
1 files of length 18
6 files of length 19
5 files of length 20
1 file of length 21
2 files of length 22
1 file of length 23
1 file of length 26
---
N=194 files total, sum of lengths S = 2315
It does not require higher mathematics to see that n can essentially be
expressed through the formula
n = 78 / (S + l * 194 + 10 * 194)
or
n = 4020 / (S/N + l + 10)
Recalling that S/N + l is the average length of a filename in the set, one
can nearly guess that the readdir bug occurs usually after a single block
of directory entries has been filled, where a block is a little less than
4096 bytes and a directory entry consists of the filename, 2 bytes of
alignment and 8 bytes of data.
Thus, instead of testing whether the number of directory entries since the
last rewind() exceeds a fixed number, a better test is probably whether
(total length of file names since last rewind()
+ 10 * number of directory entries since last rewind())
a fixed number such as 3000
Bruno
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)
Bruno Haible [EMAIL PROTECTED] wrote: Jim Meyering wrote: I'll use 180. The lower we go, the more of a performance penalty we impose for directories with very many entries. I tried the value 180. It worked fine in some cases, but still failed in others: ... Thus, instead of testing whether the number of directory entries since the last rewind() exceeds a fixed number, a better test is probably whether (total length of file names since last rewind() + 10 * number of directory entries since last rewind()) a fixed number such as 3000 Thanks for the quick test and analysis! Considering all of that, I may just keep the code simple and make rm always do an extra rewind on Darwin. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Darwin - chmod broken?
Paul Eggert wrote: mwoehlke [EMAIL PROTECTED] writes: 10487 chmodCALL chmod(0x2800600,0x1a4) 10487 chmodNAMI . 10487 chmodRET chmod 0 10487 chmodCALL chmod(0x2800600,0x1a4) 10487 chmodNAMI b 10487 chmodRET chmod 0 10487 chmodCALL close(0x1) 10487 chmodRET close 0 10487 chmodCALL exit(0) Does that look right? No. It looks like your kernel is busted. The first chmod sets the permissions of . to 644, i.e., nobody can search it. But the second chmod searches . successfully. Yup, that's what I'm seeing. Are you running this test as root? Nope. If I am reading 'man 2 chmod' right, the second chmod() is expected to fail with EACCES? Yes, that's right. It looks like your operating system is buggy. Wow... you ain't kidding... $ ll -d . b drwxr-xr-x 3 install sstest 512 Sep 27 08:26 . drwxr-xr-x 2 install sstest 512 Sep 26 15:20 b $ /bin/chmod a-x . b $ ll -d . b drw-r--r-- 3 install sstest 512 Sep 27 08:26 . drw-r--r-- 2 install sstest 512 Sep 26 15:20 b $ ll -d . b drw-r--r-- 3 install sstest 512 Sep 27 08:26 . drw-r--r-- 2 install sstest 512 Sep 26 15:20 b $ chmod a+x . chmod: changing permissions of `.': Permission denied $ chmod a+x b chmod: cannot access `b': Permission denied $ /bin/chmod a+x . chmod: .: Permission denied $ ll -d . b ls: .: Permission denied ls: b: Permission denied $ WTF just happened there?! :-) Apparently the permissions are being cached and not flushed immediately as far as access control, but are being returned accurately for 'ls'... that's pretty messed up. So I guess this failure is a red herring at least as far as anything being wrong with coreutils. Wow, that's a broken OS/kernel/driver/one-of-the-above... (Might be the NFS driver, since this didn't break when run on a local mount.) Can you reproduce this bug with /bin/chmod? Yup (See above). I'll investigate the other failures, but if I can demonstrate that a: the OS is broken, and b: the OS's version of the same utility is similarly broken, I'll just leave my reports at that (unless someone objects to this plan). Anyway, thanks for all the help! -- Matthew The hippo made me do it! What? What do you mean you can't see the hippo? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Darwin - chmod broken?
mwoehlke [EMAIL PROTECTED] wrote: I'll investigate the other failures, but if I can demonstrate that a: the OS is broken, and b: the OS's version of the same utility is similarly broken, I'll just leave my reports at that (unless someone objects to this plan). Fine by me, especially since I'm seeing no test failures on the newer Darwin 8.7.0. Thanks for playing along :-) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-gnulib] Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)
Jim, Is there any type of file system where readdir works? I tried only HFS+ mounts (on two different volumes). What version of Darwin are you using? Darwin 7.9.0 = MacOS X 10.3.9. I see no failure with Darwin-8.7.0, so I might add a run-test (like coreutils' old readdir.m4), if it's likely to be independent of file system type. I will test and report for other file systems. In the run test, you can use /bin/rm, since /bin/rm has the same bug as the one you are fixing for GNU rm. Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cvs build error with Apple-installed tools (Re: OT: latest stable version not recommended)
[EMAIL PROTECTED] writes: Seriously, would you take a look at my post's attachment above that started this subthread, please? Sorry, I haven't a clue what started this thread. It was the make that raised the bison error, not the bootstrap script. After a bootstrap, when you do a 'make', you may need developer tools like Bison. But if you do a 'make' off a distribution tarball, you should not need Bison. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cvs build error with Apple-installed tools (Re: OT: latest stable version not recommended)
[EMAIL PROTECTED] wrote: ADC bug for it -- but now we must also add bison-2.3 and m4-1.4.7 to the growing list of requisites, with no documentation saying so, these were learned on the job so to speak. ;) No, not at all. Bison 2.3 and M4 1.4.7 will not be prerequisites for building coreutils 6.3. They are prerequisites for bootstrapping coreutils, but you don't need to bootstrap to build. Seriously, would you take a look at my post's attachment above that started this subthread, please? It was the make that raised the bison error, not the bootstrap script. (now we _are_ back on-topic ;) ) There are two things happening here and I think you are confusing them with each other. 1) CVS checkout and build as a developer. Needs a full development suite of current tools. You are checking out raw source and building everything from scratch. Needs bison. Needs m4. Etc. 2) Building from a dist image. (e.g. released tar.gz) Need basic tools only. Do not need bison. Do not need m4. All of those components are pre-built and shipped in the release image. If you modify a source file then of course you then need the required tools to process whatever changes you make. But then you are slipping back into the developer role again. If you don't change anything then the files will already be ready to go. CVS checkout and build gets you the latest bits but then you need everything. Using a dist image is much easier but then you must wait for a developer to build and distribute an image. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
