| Summary: | src_unpack(): gzip: stdout: Broken pipe - phase-helpers.sh, line 312: Called __assert_sigpipe_ok 'failure unpacking ...' | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | junkmail |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | chris, chrisstankevitz, fthtmn+gentoo, maurel.fabien, openhs, rei4dan, Thomas.Rausch |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=490310 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
output of emerge --info
Environment file Debug log New debug.log |
||
|
Description
junkmail
2013-02-18 18:00:16 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. 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'. That's a strange problem. Maybe it helps if you run it inside of a session of app-misc/screen or app-misc/tmux? What versions of tar and gzip do you have? Have you tried to rebuild them? Maybe rebuild bash too. Created attachment 339508 [details]
Environment file
Rebuilding tar, gzip and bash didn't help. Running the emerge in screen also didn't help. Thanks Version info: app-arch/tar-1.26 app-arch/gzip-1.5 (Sorry for multiple posts, can't see how to edit one) 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 Created attachment 339510 [details]
Debug log
Actually, please create the debug log without --pretend. We actually need to see the build failure in the log. Sorry. Created attachment 339512 [details]
New debug.log
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.
(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? There are files with '#' (and '~') in their name in cyrus-sasl; is it possible that these rather uncommon filenames causes this bug? (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). 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. (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). 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. 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. 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. 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. 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. 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.
*** Bug 511466 has been marked as a duplicate of this bug. *** |
