close 13516
stop
(triaging old bugS)
Hello,
On 03/02/13 10:33 PM, Paul Eggert wrote:
On 02/01/2013 05:40 PM, Global Odey wrote:
I'm afraid I'm still puzzled. Still, the patch improves things, since it fixes
what appears to be a serious bug [...]
>
http://git.savannah.gnu.org/cgit/gnulib.git
On 02/01/2013 05:40 PM, Global Odey wrote:
> 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.
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
On 01/30/2013 03:59 PM, Global Odey wrote:
> 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
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
On 01/29/2013 09:11 AM, Global Odey wrote:
> + test-getcwd
> + Exit 7
Evidently the test-getcwd program is encountering
the failure marked "fail = 7;" in that program.
Can you use GDB to debug the situation?
Try running something like this:
gdb test-getcwd
b getcwd
r
fin
p errno
That sort of thi
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.
On 01/28/2013 09:55 AM, Global Odey wrote:
> it causes test-getcwd.sh to fail now.
OK, how about the attached patch instead?
Unless you have developer tools such as autoconf, please
patch just lib/getcwd.c and gnulib-tests/test-getcwd.c;
don't apply the patch to getcwd-abort-bug.m4.
diff --git a/C
Global Odey wrote, On 01/28/2013 12:55 PM:
> 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 c
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
On 01/24/2013 12:35 PM, Assaf Gordon wrote:
> With this patch, the recursive loop is gone, but it leads to another bug:
> descending into the directory (due to "-r") doesn't work.
Thanks, can you please try this patch instead?
It's a bit more drastic, but I hope it fixes the loop
without introdu
Hello,
Paul Eggert wrote, On 01/24/2013 12:03 PM:
> Thanks, could you please try the following patch?
> This is a gnulib patch, so it also fixes modules/fdopendir --
> you needn't worry about that part of the patch,
> as it doesn't apply to coreutils.
> I'm CC'ing this possible patch to bug-gnulib
Thanks, could you please try the following patch?
This is a gnulib patch, so it also fixes modules/fdopendir --
you needn't worry about that part of the patch,
as it doesn't apply to coreutils.
I'm CC'ing this possible patch to bug-gnulib to give
the Gnulib people a heads-up.
By the way, do you ha
Paul Eggert wrote, On 01/23/2013 02:19 AM:
> It looks like there's no way to get the equivalent of strace, then.
> That's too bad. I guess you'll have to use GDB, then.
Here's what I get with GDB.
Seems like some weird case of endless recursion, that leads to file-descriptor
exhaustion (if I un
It looks like there's no way to get the equivalent of strace, then.
That's too bad. I guess you'll have to use GDB, then.
Paul Eggert wrote, On 01/22/2013 03:21 PM:
> On 01/22/13 11:22, Assaf Gordon wrote:
>> 3. Running with 'sudo', 'rm' doesn't fail:
>> $ sudo dtruss $D/rm -r $D/a $D/b 2>/tmp/rm_trace.txt
>
> You need a sudo inside dtruss, to, right?
> Something like this
>
>sudo dtruss sudo -u $USER $D/rm
On 01/22/13 11:22, Assaf Gordon wrote:
> 3. Running with 'sudo', 'rm' doesn't fail:
> $ sudo dtruss $D/rm -r $D/a $D/b 2>/tmp/rm_trace.txt
You need a sudo inside dtruss, to, right?
Something like this
sudo dtruss sudo -u $USER $D/rm -r $D/a $D/b 2>/tmp/rm_trace.txt
Paul Eggert wrote, On 01/22/2013 02:01 AM:
> Thanks, to help debug that can you please try the following
> shell commands? The idea is to run the newly-built "rm" in
> a directory that is not readable.
>
> cd coreutils-8.20/src
> D=$(pwd)
> mkdir -p a/1 b c d/2 e/3
> cd c
> chmod u=x,go= .
> ktra
Thanks, to help debug that can you please try the following
shell commands? The idea is to run the newly-built "rm" in
a directory that is not readable.
cd coreutils-8.20/src
D=$(pwd)
mkdir -p a/1 b c d/2 e/3
cd c
chmod u=x,go= .
ktrace -o /tmp/tr $D/rm -r $D/a $D/b
kdump /tmp/tr
The "ktrace" sh
On 01/21/2013 07:51 PM, Assaf Gordon wrote:
Hello,
Testing the latest coreutils on Mac OS X, "tests/rm/unread3" fails.
The immediate cause is:
"rm: unable to record current working directory: Too many open files"
Attached is the relevant part from the log file.
The programs were compiled u
Hello,
Testing the latest coreutils on Mac OS X, "tests/rm/unread3" fails.
The immediate cause is:
"rm: unable to record current working directory: Too many open files"
Attached is the relevant part from the log file.
The programs were compiled using:
===
$ ./configure CC=clang
## - ##
21 matches
Mail list logo
