[thread 1][x86_64-pc-linux-gnu-gcc -pthread] core/io.o [thread 10][x86_64-pc-linux-gnu-gcc -pthread] core/static.o /var/tmp/portage/www-servers/uwsgi-2.0.18/temp/environment: line 4935: 27 Segmentation fault python uwsgiconfig.py --build gentoo * ERROR: www-servers/uwsgi-2.0.18::gentoo failed (compile phase): * building uwsgi failed * ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_no-multilib-libressl-20200516-184510 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-8.3.1 [2] x86_64-pc-linux-gnu-10.1.0 * clang version 10.0.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/10/bin /usr/lib/llvm/10 10.0.0 Available Python interpreters, in order of preference: [1] python3.8 [2] python3.7 [3] python3.6 (fallback) [4] python2.7 (fallback) [5] pypy3 (fallback) Available Ruby profiles: [1] ruby24 (with Rubygems) [2] ruby25 (with Rubygems) * Available Rust versions: [1] rust-bin-1.43.1 * [2] rust-1.43.1 The Glorious Glasgow Haskell Compilation System, version 8.0.2 timestamp(s) of HEAD at this tinderbox image: /var/db/repos/gentoo Wed 20 May 2020 10:35:27 PM UTC /var/db/repos/libressl Sun 10 May 2020 08:35:26 PM UTC emerge -qpvO www-servers/uwsgi [ebuild N ] www-servers/uwsgi-2.0.18 USE="caps embedded libressl pcre perl routing ssl xml -apache2 -cgi -debug -expat -go -jemalloc -json -lua -mono -php -python -python-asyncio -python-gevent -ruby (-selinux) -yajl -yaml -zeromq" PHP_TARGETS="php7-2 -php7-3 -php7-4" PYTHON_TARGETS="python2_7 python3_7 -python3_6" RUBY_TARGETS="ruby24 ruby25 -ruby26" UWSGI_PLUGINS="cache carbon cheaper_busyness corerouter fastrouter http logfile logsocket mongodblog nagios ping rawrouter redislog router_basicauth router_cache router_expires router_hash router_http router_memcached router_metrics router_redirect router_redis router_rewrite router_static router_uwsgi rpc rrdtool rsyslog signal spooler sslrouter symcall syslog transformation_chunked transformation_gzip transformation_offload transformation_tofile ugreen zergpool -alarm_curl -alarm_xmpp -clock_monotonic -clock_realtime -curl_cron -dumbloop -echo -emperor_amqp -emperor_pg -emperor_zeromq -forkptyrouter -geoip -graylog2 -ldap -legion_cache_fetch -logcrypto -logpipe -notfound -pam -rados -router_access -router_radius -router_spnego -router_xmldir -sqlite -ssi -stats_pusher_statsd -systemd_logger -transformation_toupper -tuntap -webdav -xattr -xslt -zabbix"
Created attachment 640632 [details] emerge-info.txt
Created attachment 640634 [details] emerge-history.txt
Created attachment 640636 [details] environment
Created attachment 640638 [details] etc.portage.tbz2
Created attachment 640640 [details] logs.tbz2
Created attachment 640642 [details] temp.tbz2
Created attachment 640644 [details] www-servers:uwsgi-2.0.18:20200520-232319.log
Probably a bug #680058
Sergei, I have the feeling that -j1 is better than disabling sandbox for the ebuild; would you agree with that? If so... I'll just enforce -j1
Created attachment 641982 [details, diff] process.patch (In reply to Ultrabug from comment #9) > Sergei, I have the feeling that -j1 is better than disabling sandbox for the > ebuild; would you agree with that? > > If so... I'll just enforce -j1 Sergei, I took the liberty of CCing you. I can confirm that passing CPUCOUNT=1 to the environment fixes the build. I have also replaced threads with processes (see attached patch) and the build works fine. What do you think? Should I try to send the patch upstream?
Sergei, I took the liberty of CCing you. I can confirm that passing CPUCOUNT=1 to the environment fixes the build. I have also replaced threads with processes (see attached patch) and the build works fine. What do you think? Should I try to send the patch upstream? (resending message because I didn't add the CC with the patch).
(In reply to Ultrabug from comment #9) > Sergei, I have the feeling that -j1 is better than disabling sandbox for the > ebuild; would you agree with that? > > If so... I'll just enforce -j1 Yeah, -j1 sounds very reasonable. (In reply to Louis Sautier (sbraz) from comment #11) > Sergei, I took the liberty of CCing you. > > I can confirm that passing CPUCOUNT=1 to the environment fixes the build. > > I have also replaced threads with processes (see attached patch) and the > build works fine. What do you think? Should I try to send the patch upstream? > > (resending message because I didn't add the CC with the patch). It's really a sandbox bug (or limitation). Switching from threads to processes should work it around. But I would understand if upstream decides against acepting it.
(In reply to Sergei Trofimovich from comment #12) > It's really a sandbox bug (or limitation). Switching from threads to > processes should work it around. But I would understand if upstream decides > against acepting it. Well it also fails for other people so I thought it might be worth considering: https://github.com/unbit/uwsgi/issues/1318
Created attachment 646126 [details] Log from the failed build Having the same build failure on stable amd64. Setting CPUCOUNT=1 in the environment worked around the problem.
Fixed by adding CPUCOUNT=1; here's the diff diff --git a/www-servers/uwsgi/uwsgi-2.0.18.ebuild b/www-servers/uwsgi/uwsgi-2.0.18.ebuild index 1f61916e28d..fe97b6c8493 100644 --- a/www-servers/uwsgi/uwsgi-2.0.18.ebuild +++ b/www-servers/uwsgi/uwsgi-2.0.18.ebuild @@ -267,7 +267,7 @@ python_install_symlinks() { src_compile() { mkdir -p "${T}/plugins" || die - python uwsgiconfig.py --build gentoo || die "building uwsgi failed" + CPUCOUNT=1 python uwsgiconfig.py --build gentoo || die "building uwsgi failed" if use go ; then python uwsgiconfig.py --plugin plugins/gccgo gentoo || die "building plugin for go failed"
