Date: Sat, 22 Jul 2000 19:01:40 +0100 From: Ben Smithurst <ben@FreeBSD.org> To: System Administrator <admin@chemcomp.com> Cc: Rahul Siddharthan <rsidd@physics.iisc.ernet.in>, freebsd-questions@FreeBSD.ORG Subject: Re: Tar bug??? Message-ID: <20000722190140.R64132@strontium.scientia.demon.co.uk> In-Reply-To: <3978C2AF.7A6362D4@chemcomp.com> References: <3978A6F6.55C3E578@chemcomp.com> <20000722021522.A8449@physics.iisc.ernet.in> <3978C2AF.7A6362D4@chemcomp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
System Administrator wrote:
> #3 0x8052292 in msg_perror (
> str=0x80825c0 "read error at byte %ld reading %d bytes in file %s")
> at port.c:1138
>
> vfprintf (stderr, str, args);
>
> But I can't just display the value of args and I really don't understand
> (and never did) the whole va_arg() working principles.
>
> (gdb) print args
> No symbol "args" in current context.
> (gdb)
That's because of optimizations -- if you compile without optimizations you
can print "args", though it's not very useful.
Something is going wrong though. With some debugging:
stderr=0x808c090 str=0x80862a0 (read error at byte %ld reading %d bytes in file %s)
arg[0]=0x0
arg[1]=0x0
arg[2]=0x200
arg[3]=0x80980d5
There's an extra argument with value 0x0 which isn't needed. Note that
arg[1] corresponds to the "byte %ld" value, arg[2] is the "reading %d
bytes" value (512, bufsiz), and arg[3] is the pointer to the filename.
These should all be shifted one forwards, so that arg[2] ends up as the
string pointer.
I'm not sure why that's happening though. :-(
When I add more debugging,
--- port.c 2000/07/12 00:59:32 1.7
+++ port.c 2000/07/22 17:57:44
@@ -1130,6 +1130,19 @@
{
va_list args;
int save_e;
+ int i;
+
+ if (str != NULL)
+ msg_perror(NULL, 1, 2, 3);
+
+ printf("stderr=%p str=%p (%s)\n", stderr, str, str);
+ va_start(args, str);
+ for (i = 0; i < 4; i++)
+ printf("arg[%d]=%p\n", i, va_arg(args, void *));
+ va_end(args);
+
+ if (str == NULL)
+ return;
save_e = errno;
fflush (msg_file);
I see this:
ben@platinum:~/tmp/tar$ MALLOC_OPTIONS=J ./tar -f /dev/null -A -v -C . /nfs/magnesium/usr
p=/nfs/magnesium/usr
stderr=0x808c0b0 str=0x0 ((null))
arg[0]=0x1
arg[1]=0x2
arg[2]=0x3
arg[3]=0x0
stderr=0x808c0b0 str=0x80862c0 (read error at byte %ld reading %d bytes in file %s)
arg[0]=0x0
arg[1]=0x0
arg[2]=0x200
arg[3]=0x80980d5
./tar: zsh: segmentation fault (core dumped) MALLOC_OPTIONS=J ./tar -f /dev/null -A -v -C . /nfs/magnesium/usr
so, when msg_perror(NULL, 1, 2, 3) is called the arguments are passed
correctly. Weird. Anyone else have any ideas?
> Something very strange is that it crashes only when accessing
> 'automounted' directories:
Not true, it crashes on any NFS directory for me. I suspect this is
because read() fails on directories on some filesystems, including NFS.
There's some other broken-ness in tar (well, it is GNU stuff):
ben@platinum:~/tmp/tar$ ./tar -f /dev/null -A -v -C .
p=
stderr=0x808c090 str=0x8086277 (can't open file %s)
arg[0]=0x80950b5
arg[1]=0xbfbff3dc
arg[2]=0x80481c9
arg[3]=0x7
./tar: can't open file : No such file or directory
ben@platinum:~/tmp/tar$ MALLOC_OPTIONS=J !!
MALLOC_OPTIONS=J ./tar -f /dev/null -A -v -C .
p=ÐÐÐÐÐÐÐÐÐÐÐ
stderr=0x808c090 str=0x8086277 (can't open file %s)
arg[0]=0x80950b5
arg[1]=0xbfbff3c8
arg[2]=0x80481c9
arg[3]=0x7
./tar: can't open file ÐÐÐÐÐÐÐÐÐÐÐ : No such file or directory
Whichever idiot wrote it assumed malloc returns zero filled memory.
--
Ben Smithurst / ben@FreeBSD.org / PGP: 0x99392F7D
FreeBSD Documentation Project /
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000722190140.R64132>