OK, here's what I see in the 'strace' output, repeated 15
thousand-some-odd times:

write(1, "nfo\nc0121610 t __constant_c_and_"..., 10240) = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---

So for some reason gtar is ignoring the SIGPIPE signal.  There's
probably something else going wrong in Amanda, which is causing it to
close the pipe into which tar is writing.  You can probably find out
whats going on by looking at the 'sendbackup' debug logs on the
client, and I expect that if you fix the Amanda-side problem, you
won't see any more trouble from GNU tar.

The question is, why isn't tar doing the right thing when this happens?

I tested my local copy of tar like this:
$ strace -f tar -cf - . 2>/tmp/trace | true; tail /tmp/trace
mmap(NULL, 821, PROT_READ, MAP_SHARED, 3, 0) = 0x2af4a8ffb000
lseek(3, 821, SEEK_SET)                 = 821
munmap(0x2af4a8ffb000, 821)             = 0
close(3)                                = 0
lstat("./ABOUT-NLS", {st_mode=S_IFREG|0644, st_size=38475, ...}) = 0
open("./ABOUT-NLS", O_RDONLY)           = 3
read(3, "Notes on the Free Translation Pr"..., 9216) = 9216
write(1, "./\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
10240) = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
+++ killed by SIGPIPE +++

I'm running tar 1.19, and also tested this against 1.15 and 1.13.25,
and saw similar (that is, correct) behavior everywhere.  What version
of tar are you running?

Dustin