Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 698832 - www-client/firefox-71.0 - SystemError: Objects/codeobject.c:112: bad argument to internal function
Summary: www-client/firefox-71.0 - SystemError: Objects/codeobject.c:112: bad argument...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Mozilla Gentoo Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-29 09:08 UTC by Laslo Hunhold
Modified: 2020-09-13 06:38 UTC (History)
1 user (show)

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


Attachments
build.log.bz2 (build.log.bz2,42.00 KB, application/x-bzip)
2019-10-29 09:11 UTC, Laslo Hunhold
Details
emerge.info (emerge.info,6.12 KB, text/plain)
2019-10-29 09:13 UTC, Laslo Hunhold
Details
build-71.0.log.bz2 (build-71.0.log.bz2,522.49 KB, application/x-bzip)
2019-12-15 14:28 UTC, Laslo Hunhold
Details
build-71.0-makeopts-dir.log (build-71.0-makeopts-dir.log,169.45 KB, text/plain)
2019-12-16 07:44 UTC, Laslo Hunhold
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Laslo Hunhold 2019-10-29 09:08:27 UTC
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
Comment 1 Laslo Hunhold 2019-10-29 09:11:23 UTC
Created attachment 594340 [details]
build.log.bz2
Comment 2 Laslo Hunhold 2019-10-29 09:13:08 UTC
Created attachment 594342 [details]
emerge.info
Comment 3 Laslo Hunhold 2019-11-07 06:46:05 UTC
The emerge of www-client/firefox-70.0.1 was successful, so this might have been an upstream issue of some kind.
Comment 4 Laslo Hunhold 2019-12-14 08:28:00 UTC
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
Comment 5 Jory A. Pratt gentoo-dev 2019-12-14 13:18:00 UTC
(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.
Comment 6 Laslo Hunhold 2019-12-15 14:28:19 UTC
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.
Comment 7 Jory A. Pratt gentoo-dev 2019-12-16 00:13:55 UTC
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.
Comment 8 Laslo Hunhold 2019-12-16 07:44:52 UTC
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.
Comment 9 Laslo Hunhold 2019-12-30 22:08:21 UTC
It works again with 71.0-r1 and seems to have been related to the cbindgen-build-bug. Thanks for the suggestions!
Comment 10 kevinmbecause 2020-04-29 06:16:05 UTC
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}" \
Comment 11 Laslo Hunhold 2020-04-29 09:58:52 UTC
(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.
Comment 12 Laslo Hunhold 2020-09-13 06:37:35 UTC
Firefox emerges have been working consistently for me in the last few months, so this bug can be closed in my opinion.