Re: Child died with signal 13

[Randall R Schulz <rrschulz at cris dot com>]

Volker,

I don't think there's a problem here, actually.

I occasionally get these diagnostics, too, but there's never a problem 
extracting the files from the archive. Apparently tar knows it's seen the 
last TOC entry and closes the pipe from the gunzip sub-process. Then it 
waits for that process to exit. Since gunzip doesn't explicitly handle 
SIGPIPE and terminate gracefully, its death at the hand of the SIGPIPE is 
reported to tar and tar then dutifully reports it to you.

I retrieved your test file and got the same result as you. Aside from the 
diagnostic, which I got for this file and get for others sometimes, I've 
had no trouble with tar.

I can't tell for sure if "a/error.txt" was retrieved accurately, so here's 
the checksum for that file as extracted on my system:

% sum a/error.txt
28232     9


However, by using tar's "-i" option:

-i, --ignore-zeros             ignore zeroed blocks in archive (means EOF)

the error was suppressed. I'm guessing it forces tar to read all the data 
in the uncompressed input file instead of quitting early.


My recommendation is that you ignore this error. If you're concerned about 
the data integrity, you can use the "-t --test" option to gunzip to check 
the data in your gzip-ed files before submitting them to tar.

Randall Schulz
Mountain View, CA USA


At 06:46 2002-03-01, Volker Quetschke wrote:
>Hi,
>
>>Signal numbers and errno codes (and process status codes) are distinct. 
>>Process status codes to incorporate the signal number when a signal 
>>caused the death of the process.
>>
>>Signal 13 is SIGPIPE: Write to a pipe with no process there to read the 
>>data. In your context, this means the tar process has closed the pipe 
>>because it has concluded there is no more data to be retrieved from the 
>>gunzip sub-process it started in response to the 'z' option. If tar 
>>didn't do this, it would have to read all the gunzip-ed data. If it 
>>didn't either close the pipe (leading to the signal) or read the data, 
>>the child would just block and those processes would stall (at least 
>>until you or some other external action killed the tar + gunzip process group).
>
>
>I have no idea where the problem is, but I got one ME TOO which confirmed 
>that not only I have the problem with tar saying: "Child died with signal 
>13". So, Windows 2000, Windows 2000 Server and Windows NT4 SP6 have the 
>problem, Windows 98 and any other *nix machine I testet have not. I think 
>it's cygwin related!
>
>Because I have no idea where to look in the cygwin sources I decided the 
>only way to help the developers *YOU* is to build a more simple testcase. 
>Here it comes:
>
>--------------------------
>Administrator@LISI ~/qqq
>$ tar -czvf a.tar.gz a/
>a/
>a/error.txt
>
>Administrator@LISI ~/qqq
>$ tar -tzvf a.tar.gz
>drwxrwxrwx Administratoren/Kein 0 2002-03-01 14:22:18 a/
>-rwxrwxrwx Administratoren/Kein 8193 2002-03-01 14:21:15 a/error.txt
>tar: Child died with signal 13
>tar: Error exit delayed from previous errors
>
>Administrator@LISI ~/qqq
>$ tar -cvf a.tar a/
>a/
>a/error.txt
>
>Administrator@LISI ~/qqq
>$ ll
>total 21
>drwxrwxrwx    2 Administ Kein            0 Mar  1 14:22 a
>-rw-rw-rw-    1 Administ Kein        20480 Mar  1 14:26 a.tar
>-rw-rw-rw-    1 Administ Kein          299 Mar  1 14:23 a.tar.gz
>--------------------------
>
>You can get a.tar.gz at: http://www.scytek.de/a.tar.gz . The problem is 
>related to the length of the tar file. If you delete one charakter in 
>error.txt, and its length drops to 8192 then the length of the tar file 
>drops to 10240 bytes and you don't get the "tar: Child died with signal 
>13". I didn't test how many bytes one has to add to let the error vanish.
>
>Hope this makes it easy to find the problem.
>
>   Volker


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/