Emerging www-client/firefox-70.0 fails (see attached log) at some point with the error: SystemError: Objects/codeobject.c:112: bad argument to internal function It has a long traceback attached to it and I couldn't quite untangle it. Reproducible: Always
Created attachment 594340 [details] build.log.bz2
Created attachment 594342 [details] emerge.info
The emerge of www-client/firefox-70.0.1 was successful, so this might have been an upstream issue of some kind.
I hate to reopen this bug, but after firefox-70.0.1 compiled fine on 2019-11-07 it fails again for the same reason now. firefox-71.0 fails too, but I masked it temporarily so I can pin down the problem. If we look at the git-log of the ebuild for 70.0.1, there were rust-related changes after my last successful emerge (on 2019-11-07), but this seems to be a problem with python rather than Rust, if we take a look again at the traceback that is given after the error. 8 0:31.29 Traceback (most recent call last): 8 0:31.29 File "/var/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/config/pythonpath.py", line 60, in <module> 8 0:31.29 main(sys.argv[1:]) 8 0:31.29 File "/var/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/config/pythonpath.py", line 50, in main 8 0:31.29 execfile(script, frozenglobals) 8 0:31.29 File "/var/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/python/mozbuild/mozbuild/action/xpidl-process.py", line 16, in <module> 8 0:31.29 from xpidl import jsonxpt 8 0:31.29 File "/var/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/build/mach_bootstrap.py", line 406, in __call__ 8 0:31.29 module = self._original_import(name, globals, locals, fromlist, level) 8 0:31.29 File "/var/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/xpcom/idl-parser/xpidl/jsonxpt.py", line 10, in <module> 8 0:31.29 import xpidl 8 0:31.29 File "/var/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/build/mach_bootstrap.py", line 406, in __call__ 8 0:31.29 module = self._original_import(name, globals, locals, fromlist, level) 8 0:31.29 SystemError: Objects/codeobject.c:112: bad argument to internal function 8 0:31.30 gmake[5]: *** [Makefile:50: toolkit_antitracking.xpt] Error 1 8 0:31.30 gmake[5]: Leaving directory '/var/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/ff/config/makefiles/xpidl' 8 0:31.30 gmake[4]: *** [Makefile:15: export] Error 2 I'd be happy to test some things out, but given the compile times (as you can see the error only occurs 30 minutes, right at the end of the compilation of firefox) I don't want to do that blindly. Does anybody have some pointers to what I could try out? [0]: https://gitweb.gentoo.org/repo/gentoo.git/log/www-client/firefox/firefox-70.0.1.ebuild
(In reply to Laslo Hunhold from comment #4) > I hate to reopen this bug, but after firefox-70.0.1 compiled fine on > 2019-11-07 it fails again for the same reason now. firefox-71.0 fails too, > but I masked it temporarily so I can pin down the problem. > > If we look at the git-log of the ebuild for 70.0.1, there were rust-related > changes after my last successful emerge (on 2019-11-07), but this seems to > be a problem with python rather than Rust, if we take a look again at the > traceback that is given after the error. > > 8 0:31.29 Traceback (most recent call last): > 8 0:31.29 File > "/var/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/config/ > pythonpath.py", line 60, in <module> > 8 0:31.29 main(sys.argv[1:]) > 8 0:31.29 File > "/var/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/config/ > pythonpath.py", line 50, in main > 8 0:31.29 execfile(script, frozenglobals) > 8 0:31.29 File > "/var/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/python/mozbuild/ > mozbuild/action/xpidl-process.py", line 16, in <module> > 8 0:31.29 from xpidl import jsonxpt > 8 0:31.29 File > "/var/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/build/ > mach_bootstrap.py", line 406, in __call__ > 8 0:31.29 module = self._original_import(name, globals, locals, > fromlist, level) > 8 0:31.29 File > "/var/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/xpcom/idl-parser/ > xpidl/jsonxpt.py", line 10, in <module> > 8 0:31.29 import xpidl > 8 0:31.29 File > "/var/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/build/ > mach_bootstrap.py", line 406, in __call__ > 8 0:31.29 module = self._original_import(name, globals, locals, > fromlist, level) > 8 0:31.29 SystemError: Objects/codeobject.c:112: bad argument to internal > function > 8 0:31.30 gmake[5]: *** [Makefile:50: toolkit_antitracking.xpt] Error 1 > 8 0:31.30 gmake[5]: Leaving directory > '/var/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/ff/config/ > makefiles/xpidl' > 8 0:31.30 gmake[4]: *** [Makefile:15: export] Error 2 > > I'd be happy to test some things out, but given the compile times (as you > can see the error only occurs 30 minutes, right at the end of the > compilation of firefox) I don't want to do that blindly. Does anybody have > some pointers to what I could try out? > > [0]: > https://gitweb.gentoo.org/repo/gentoo.git/log/www-client/firefox/firefox-70. > 0.1.ebuild That isn't the error. You will need to be able to produce with 71.x if you want support.
Created attachment 599618 [details] build-71.0.log.bz2 Isn't SystemError: Objects/codeobject.c:112: bad argument to internal function the error? I completely understand the point with 71.x, so I reproduced the error with 71.0 (see the new build.log.bz2), yielding the same error message SystemError: Objects/codeobject.c:112: bad argument to internal function Let me know if I can give you more info on build-dependencies or tweaks I could test out.
If you would please test with MAKEOPTS="-j4 -l4" and see if it is reproducible please. If it fails go into ${PORTDIR}/www-client/firefox && ebuild firefox-71.0.ebuild install and see if it fails please.
Created attachment 599698 [details] build-71.0-makeopts-dir.log (In reply to Jory A. Pratt from comment #7) > If you would please test with MAKEOPTS="-j4 -l4" and see if it is > reproducible please. If it fails go into ${PORTDIR}/www-client/firefox && > ebuild firefox-71.0.ebuild install and see if it fails please. Dear Jory, thank you for the suggestions! I first tried emerging with the MAKEOPTS-trick, to no avail, and then tried to emerge it inside /usr/portage/www-client/firefox and using MAKEOPTS="-j4 -l4", which also failed. What I noticed though was that the error now occurs much sooner after around a minute or so much earlier in the build process. You can find the log in the attachment (build-71.0-makeopts-dir.log). Do you see anything interesting in there? From what I can tell, it fails for the same reason. Please let me know if I can test anything else out; I'll be happy to do it! Just two pointers: I am running an "old" Gentoo installation (which e.g. lead to bug 643302 and might be a factor) and enabled all system-* USE-flags for firefox.
It works again with 71.0-r1 and seems to have been related to the cbindgen-build-bug. Thanks for the suggestions!
I have this same problem in the stable 68.7.0 and unstable 75.0. It also happens in the stable dev-lang/spidermonkey-60.5.2_p0-r4. The failure is random and happens at different times on different files. MAKEOPTS="-j1" has no effect. Running ebuild [...] install a few times will allow it to compile correctly and I am currently posting this from the resulting build. I don't know a proper fix, but I added a for loop to the ebuild to retry the compilation 10 times before dying. Here is the patch: --- firefox-68.7.0.ebuild 2020-04-23 14:09:40.000000000 -0400 +++ firefox-68.7.0-r1.ebuild 2020-04-25 05:08:56.058563640 -0400 @@ -635,6 +635,14 @@ addpredict /etc/gconf fi + for ((i=0; i<10; i++)) ; do + GDK_BACKEND=x11 \ + MOZ_MAKE_FLAGS="${MAKEOPTS} -O" \ + SHELL="${SHELL:-${EPREFIX}/bin/bash}" \ + MOZ_NOSPAM=1 \ + ${_virtx} \ + ./mach build --verbose + done GDK_BACKEND=x11 \ MOZ_MAKE_FLAGS="${MAKEOPTS} -O" \ SHELL="${SHELL:-${EPREFIX}/bin/bash}" \
(In reply to kevinmbecause from comment #10) > I have this same problem in the stable 68.7.0 and unstable 75.0. It also > happens in the stable dev-lang/spidermonkey-60.5.2_p0-r4. The failure is > random and happens at different times on different files. MAKEOPTS="-j1" has > no effect. Running ebuild [...] install a few times will allow it to compile > correctly and I am currently posting this from the resulting build. I don't > know a proper fix, but I added a for loop to the ebuild to retry the > compilation 10 times before dying. Here is the patch: > --- firefox-68.7.0.ebuild 2020-04-23 14:09:40.000000000 -0400 > +++ firefox-68.7.0-r1.ebuild 2020-04-25 05:08:56.058563640 -0400 > @@ -635,6 +635,14 @@ > addpredict /etc/gconf > fi > > + for ((i=0; i<10; i++)) ; do > + GDK_BACKEND=x11 \ > + MOZ_MAKE_FLAGS="${MAKEOPTS} -O" \ > + SHELL="${SHELL:-${EPREFIX}/bin/bash}" \ > + MOZ_NOSPAM=1 \ > + ${_virtx} \ > + ./mach build --verbose > + done > GDK_BACKEND=x11 \ > MOZ_MAKE_FLAGS="${MAKEOPTS} -O" \ > SHELL="${SHELL:-${EPREFIX}/bin/bash}" \ Thanks for sharing! Admittedly, the problem has gone away for me for a few emerges. I'm really confused what the problem might be, but given the random nature it might be a race condition. Given it's not fixed by running with -j1 it might be something else.
Firefox emerges have been working consistently for me in the last few months, so this bug can be closed in my opinion.