Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 458148 - src_unpack(): gzip: stdout: Broken pipe - phase-helpers.sh, line 312: Called __assert_sigpipe_ok 'failure unpacking ...'
Summary: src_unpack(): gzip: stdout: Broken pipe - phase-helpers.sh, line 312: Calle...
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
: 511466 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-02-18 18:00 UTC by junkmail
Modified: 2014-06-11 20:43 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
output of emerge --info (info.txt,14.63 KB, text/plain)
2013-02-18 18:00 UTC, junkmail
Details
Environment file (environment,183.54 KB, text/plain)
2013-02-20 16:26 UTC, junkmail
Details
Debug log (debug.log,10.28 KB, text/plain)
2013-02-20 17:07 UTC, junkmail
Details
New debug.log (debug.log,234.11 KB, text/plain)
2013-02-20 19:37 UTC, junkmail
Details

Note You need to log in before you can comment on or make changes to this bug.
Description junkmail 2013-02-18 18:00:16 UTC
Created attachment 339270 [details]
output of emerge --info

When updating dev-libs/cyrus-sasl-2.1.25-r4 when logged in via ssh I get this error:

Emerging (2 of 10) dev-libs/cyrus-sasl-2.1.25-r4
 * cyrus-sasl-2.1.25.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ...                                                     [ ok ]
>>> Unpacking source...
>>> Unpacking cyrus-sasl-2.1.25.tar.gz to /var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/work

gzip: stdout: Broken pipe
 * ERROR: dev-libs/cyrus-sasl-2.1.25-r4 failed (unpack phase):
 *   failure unpacking cyrus-sasl-2.1.25.tar.gz
 * 
 * Call stack:
 *               ebuild.sh, line   93:  Called src_unpack
 *             environment, line 5152:  Called __eapi0_src_unpack
 *        phase-helpers.sh, line  575:  Called unpack 'cyrus-sasl-2.1.25.tar.gz'
 *        phase-helpers.sh, line  339:  Called __unpack_tar 'gzip -d'
 *        phase-helpers.sh, line  312:  Called __assert_sigpipe_ok 'failure unpacking cyrus-sasl-2.1.25.tar.gz'
 *   isolated-functions.sh, line   39:  Called die
 * The specific snippet of code:
 *              [[ $x -ne 0 && $x -ne ${PORTAGE_SIGPIPE_STATUS:-141} ]] && die "$@"
 * 
 * If you need support, post the output of `emerge --info '=dev-libs/cyrus-sasl-2.1.25-r4'`,
 * the complete build log and the output of `emerge -pqv '=dev-libs/cyrus-sasl-2.1.25-r4'`.
!!! When you file a bug report, please include the following information:
GENTOO_VM=  CLASSPATH="" JAVA_HOME=""
JAVACFLAGS="" COMPILER=""
and of course, the output of emerge --info
 * The complete build log is located at '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/temp/environment'.
 * Working directory: '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/work'
 * S: '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/work/cyrus-sasl-2.1.25'

>>> Failed to emerge dev-libs/cyrus-sasl-2.1.25-r4, Log file:

>>>  '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/temp/build.log'

 * Messages for package dev-libs/cyrus-sasl-2.1.25-r4:

 * ERROR: dev-libs/cyrus-sasl-2.1.25-r4 failed (unpack phase):
 *   failure unpacking cyrus-sasl-2.1.25.tar.gz
 * 
 * Call stack:
 *               ebuild.sh, line   93:  Called src_unpack
 *             environment, line 5152:  Called __eapi0_src_unpack
 *        phase-helpers.sh, line  575:  Called unpack 'cyrus-sasl-2.1.25.tar.gz'
 *        phase-helpers.sh, line  339:  Called __unpack_tar 'gzip -d'
 *        phase-helpers.sh, line  312:  Called __assert_sigpipe_ok 'failure unpacking cyrus-sasl-2.1.25.tar.gz'
 *   isolated-functions.sh, line   39:  Called die
 * The specific snippet of code:
 *              [[ $x -ne 0 && $x -ne ${PORTAGE_SIGPIPE_STATUS:-141} ]] && die "$@"
 * 
 * If you need support, post the output of `emerge --info '=dev-libs/cyrus-sasl-2.1.25-r4'`,
 * the complete build log and the output of `emerge -pqv '=dev-libs/cyrus-sasl-2.1.25-r4'`.
 * The complete build log is located at '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/temp/environment'.
 * Working directory: '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/work'
 * S: '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/work/cyrus-sasl-2.1.25'

 * GNU info directory index is up-to-date.
 * After world updates, it is important to remove obsolete packages with
 * emerge --depclean. Refer to `man emerge` for more information.

When I logged in physically at the machine via konsole, the emerge completed normally. This same problem occurred with the previous stable package of cyrus-sasl (2.1.23-r6), with the same workaround.
Comment 1 junkmail 2013-02-18 18:18:02 UTC
Sorry, made a mistake;

Version 2.1.23-r6 was the last stable version not affected by this issue for me. Version 2.1.25-r3 was also affected by this issue.
Comment 2 Jeroen Roovers gentoo-dev 2013-02-20 15:09:42 UTC
Please attach the environment file (from when you log in through SSH) to this bug report:

 * The ebuild environment file is located at '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/temp/environment'.
Comment 3 Zac Medico gentoo-dev 2013-02-20 16:01:46 UTC
That's a strange problem. Maybe it helps if you run it inside of a session of app-misc/screen or app-misc/tmux?
Comment 4 Zac Medico gentoo-dev 2013-02-20 16:03:39 UTC
What versions of tar and gzip do you have? Have you tried to rebuild them? Maybe rebuild bash too.
Comment 5 junkmail 2013-02-20 16:26:41 UTC
Created attachment 339508 [details]
Environment file
Comment 6 junkmail 2013-02-20 16:27:48 UTC
Rebuilding tar, gzip and bash didn't help. Running the emerge in screen also didn't help. 

Thanks
Comment 7 junkmail 2013-02-20 16:29:40 UTC
Version info:

app-arch/tar-1.26
app-arch/gzip-1.5

(Sorry for multiple posts, can't see how to edit one)
Comment 8 Zac Medico gentoo-dev 2013-02-20 16:45:55 UTC
It looks a lot like bug 309001 and bug 252680, but those are supposed to be handled by __assert_sigpipe_ok. Please reproduce the problem with --debug and attach a log created as follows:

   emerge --oneshot --pretend --debug cyrus-sas > debug.log 2>&1
   xz -9 debug.log
Comment 9 junkmail 2013-02-20 17:07:59 UTC
Created attachment 339510 [details]
Debug log
Comment 10 Zac Medico gentoo-dev 2013-02-20 17:17:41 UTC
Actually, please create the debug log without --pretend. We actually need to see the build failure in the log. Sorry.
Comment 11 junkmail 2013-02-20 19:37:28 UTC
Created attachment 339512 [details]
New debug.log
Comment 12 Zac Medico gentoo-dev 2013-02-20 20:00:56 UTC
For the failure, we have 'pipestatus=1 0' inside __assert_sigpipe_ok. Normally it's 'pipestatus=141 0' due to the SIGPIPE. So, apparently something is causing gzip to handle the SIGPIPE differently. Portage already tries to reset the SIGPIPE handler before exec, with this code:

    signal.signal(signal.SIGPIPE, signal.SIG_DFL)

I don't know what else we can do.
Comment 13 Zac Medico gentoo-dev 2013-02-20 22:52:41 UTC
(In reply to comment #5)
> Created attachment 339508 [details]
> Environment file

Is this the environment from a failed build when logged in via ssh? You should compare it the environment when you're logged on locally. You can get /var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/temp/environment after running this command:

   ebuild /usr/portage/dev-libs/cyrus-sasl/cyrus-sasl-2.1.25-r4.ebuild unpack

Is there anything special about your ssh configuration?
Comment 14 theodor 2013-04-13 20:18:13 UTC
There are files with '#' (and '~') in their name in cyrus-sasl; is it possible that these rather uncommon filenames causes this bug?
Comment 15 Zac Medico gentoo-dev 2013-04-13 23:00:51 UTC
(In reply to comment #14)
> There are files with '#' (and '~') in their name in cyrus-sasl; is it
> possible that these rather uncommon filenames causes this bug?

File names should not matter, since the problem is with the gzip exit code as described in comment #12, and gzip does not know anything about file names (only tar handles the file names).
Comment 16 theodor 2013-04-17 11:04:05 UTC
I thought so, too. But I re-compressed the tar file as bzip2 and the bug persisted. After untaring, deleting those files and then making a new .tar.bz2-file from it it worked.
Comment 17 Zac Medico gentoo-dev 2013-04-17 14:34:05 UTC
(In reply to comment #16)
That's because your new tar file doesn't trigger the case where tar closes the pipe and triggers SIGPIPE for the decompressor (see bug 309001).
Comment 18 Róbert Čerňanský 2013-07-09 15:25:44 UTC
I get this error even if I log in locally as a user and then switch to root with 'su -'.  I have to log in as root directly then it passes.
Comment 19 Chris Stankevitz 2013-10-25 20:41:19 UTC
Me too: I get this error even if I log in locally as a user and then switch to root with 'su -'.  I have to log in as root directly to get this package to build.
Comment 20 Chris Slycord 2013-11-07 02:01:18 UTC
I have the same problem with 2.1.26-r3 when logged in as a user and running su to become root. When logged in as root, everything works.
Comment 21 Chris Smith 2013-11-12 21:31:36 UTC
I suspect that this bug (which I now have) is related to a previous bug I reported:
https://bugs.gentoo.org/show_bug.cgi?id=490310

I also still have that "WORKSFORME" bug because it doesn't work for me :-)

Oddly enough, just as xterm works fine without throwing the bzip2 errors as in bug 490310, xterm also works fine for emerging cyrus-sasl. It's only when I'm in konsole that I see both bugs.
Comment 22 Róbert Čerňanský 2013-12-19 13:02:47 UTC
Perhaps the way how the cyrus-sasl tarball is extracted should be changed in the ebuild.

While remotely connected, untaring it I get:

$ tar xf /usr/portage/distfiles/cyrus-sasl-2.1.26.tar.gz 

gzip: stdout: Broken pipe
tar: Child returned status 1
tar: Error is not recoverable: exiting now

I am, however able to successfully unpack it with gunzip and tar separately:

$ gunzip /usr/portage/distfiles/cyrus-sasl-2.1.26.tar.gz
$ tar xf /usr/portage/distfiles/cyrus-sasl-2.1.26.tar
[no error]

Actually, after repacking it with tar czf ... (and updating digest) the emerge finished successfully.  It is in contradiction with comments #14+#16, I know, strange.  Also I did not found any files with ~ or # in the cyrus-sasl-2.1.26.tar.gz.
Comment 23 Pawel Kraszewski 2014-05-06 06:58:24 UTC
I know this bug is half-a-year-old, but I was hit by the exact one recently (emerging dev-lang/erlang, but the very exact symptoms).

The cause was overoptimized gzip and/or tar.

I have ~amd64 system with _very_ aggressive optimizations:

CFLAGS_GRAPHITE="-floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block"
CFLAGS_LTO="-flto=8  -ftree-vectorize"

CFLAGS="-O3 -ggdb -pipe -march=core-avx2 ${CFLAGS_GRAPHITE}"
CXXFLAGS="${CFLAGS}"
LDFLAGS="${CFLAGS_GRAPHITE} -fuse-linker-plugin"

(LTO is enabled via package.env)

This ended with "Called __assert_sigpipe_ok 'failure unpacking  ...' " for some (not all) packages, to take erlang-17 as a notable example.

When I downoptimized tar and gzip to classic 

CFLAGS="-O2 -ggdb -pipe -march=native"
CXXFLAGS="${CFLAGS}"

emerge went smoothly.
Comment 24 Jeroen Roovers gentoo-dev 2014-05-26 16:51:15 UTC
*** Bug 511466 has been marked as a duplicate of this bug. ***