• Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category Packages
  • Assigned To
    Andreas Baumann
  • Operating System pentium4
  • Severity Low
  • Priority Medium
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Arch Linux 32
Opened by Andreas Baumann - 28.03.2021
Last edited by Andreas Baumann - 10.09.2021

FS#174 - firefox 87.0 doesn't build

Again, we get into out-of-memory situations with rust:

41:24.75   cargo:warning=src/vector_type.h:502:11: warning: ‘void* memcpy(void*, const void*, size_t)’ writing to an object of type ‘struct glsl::vec4’ with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess]
41:24.75   cargo:warning=  502 |     memcpy(&v, p, sizeof(v));
41:24.75   cargo:warning=      |     ~~~~~~^~~~~~~~~~~~~~~~~~
41:24.75   cargo:warning=In file included from src/gl.cc:78:
41:24.75   cargo:warning=src/glsl.h:1772:8: note: ‘struct glsl::vec4’ declared here
41:24.75   cargo:warning= 1772 | struct vec4 {
41:24.75   cargo:warning=      |        ^~~~
41:24.75   cargo:warning=
41:24.75   cargo:warning=cc1plus: out of memory allocating 21906724 bytes after a total of 213745664 bytes

 6:42.75    Compiling geckoservo v0.0.1 (/build/firefox/src/firefox-87.0/servo/ports/geckolib)
Process Process-1:
Traceback (most recent call last):
  File "/usr/lib/python3.9/multiprocessing/process.py", line 315, in _bootstrap
  File "/usr/lib/python3.9/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/build/firefox/src/firefox-87.0/testing/mozbase/mozsystemmonitor/mozsystemmonitor/resourcemonitor.py", line 141, in _collect
    while not _poll(pipe, poll_interval=sleep_interval):
  File "/build/firefox/src/firefox-87.0/testing/mozbase/mozsystemmonitor/mozsystemmonitor/resourcemonitor.py", line 107, in _poll
    return pipe.poll(poll_interval)
  File "/usr/lib/python3.9/multiprocessing/connection.py", line 262, in poll
    return self._poll(timeout)
  File "/usr/lib/python3.9/multiprocessing/connection.py", line 429, in _poll
    r = wait([self], timeout)
  File "/usr/lib/python3.9/multiprocessing/connection.py", line 936, in wait
    ready = selector.select(timeout)
  File "/usr/lib/python3.9/selectors.py", line 416, in select
    fd_event_list = self._selector.poll(timeout)
52:46.35 make[4]: *** [/build/firefox/src/firefox-87.0/config/makefiles/rust.mk:348: force-cargo-library-build] Interrupt
52:46.35 make[3]: *** [/build/firefox/src/firefox-87.0/config/recurse.mk:72: toolkit/library/rust/target] Interrupt
52:46.35 make[2]: *** [/build/firefox/src/firefox-87.0/config/recurse.mk:34: compile] Interrupt
52:46.35 make[1]: *** [/build/firefox/src/firefox-87.0/config/rules.mk:355: default] Interrupt

Rust is 1.51.0 on both pentium4 and i686.

Closed by  Andreas Baumann
10.09.2021 06:42
Reason for closing:  Fixed
Erich Eckner commented on 28.03.2021 08:22

judging from the numbers, this does not seem too bad: its around 256MB - do we really have that few RAM on the build slaves?

Erich Eckner commented on 28.03.2021 08:40

thunderbird seems to have oom-errors, too - though, they're not in rust, but in /usr/bin/ld.bfd.

Andreas Baumann commented on 28.03.2021 08:50

Mmh. Interesting. I was off by one magnitude because the number looked so 2^31-ish.
This sounds like a limit maybe in systemd-nspawn?

I excplicitely moved to the bfs linker because of memory issues.

Andreas Baumann commented on 29.04.2021 06:26
52239 arch      20   0 2778852   2.6g   4048 R 100.0   8.4   1:33.94 ld.bfd                           
33:05.35 toolkit/library/build/libxul.so

this linking step passes.

But then I get:

0:06.08 stderr: 06:24:21 panic occurred at library/alloc/src/raw_vec.rs:537: capacity overflow\n'

which is in the middle of the Rust vec class resulting on overflows on 32-bit.

Andreas Baumann commented on 29.04.2021 06:28

0:06.08 Unexpected error: dump_syms failed to produce the expected output

So, it tries to dump all the symbols from a huge shared library file (libxul.so
presumably) into memory and fails.

In "old" times we would have written a script calling 'nm', but that is so old
fashioned. It has to be done in Rust all in memory and produce overflows.. :→

Andreas Baumann commented on 29.04.2021 10:02
Andreas Baumann commented on 05.09.2021 05:47

gcc 11 also seems to miscompile the code now

#11:28.22 /usr/include/c++/11.1.0/type_traits:2933:11: error: no type named ‘type’ in
# ‘struct std::invoke_result<nsTHashtable<nsBaseHashtableET<nsUint32HashKey, RefPtr<m
#ozilla::dom::AccessibleNode> > >::PutEntry(nsTHashtable<nsBaseHashtableET<nsUint32Ha
#shKey, RefPtr<mozilla::dom::AccessibleNode> > >::KeyType, const fallible_t&)::<lambd
#a(auto:7)>, mozilla::Maybe<nsTHashtable<nsBaseHashtableET<nsUint32HashKey, RefPtr<mo
#zilla::dom::AccessibleNode> > >::EntryHandle>&&>’
#11:28.22 2933 | using invoke_result_t = typename invoke_result<_Fn, _Args…>::

Indications go into:

# https://bugzilla.mozilla.org/show_bug.cgi?id=1713071 # https://bugzilla.mozilla.org/show_bug.cgi?id=1710235 # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100644

I patched PKGBUILD for gcc10 for now, so at least we get the old dump_syms error again. :-)

Andreas Baumann commented on 09.09.2021 08:41

dump_syms is a separate package, does rust compilation with –target x86_64-unknown-linux-gnu,
let's fix that one first..

Andreas Baumann commented on 09.09.2021 14:11

So, again dump_syms fails. This starts to point into the direction that 32-bit firefox can only be
cross-compiled from a machine with 64-bit address space?

Andreas Baumann commented on 09.09.2021 14:44

maybe we can simply not do 'mach buildsymbols'? who needs build symbols anyway.. :-)

Andreas Baumann commented on 09.09.2021 16:49
 export SOCORRO_SYMBOL_UPLOAD_TOKEN_FILE="$startdir/.crash-stats-api.token"
   make -C obj uploadsymbols
   cp -fvt "$startdir" obj/dist/*crashreporter-symbols-full.tar.zst

Phoning symbols home?


Available keyboard shortcuts


Task Details

Task Editing