- 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
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:
pentium4 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 i686 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 self.run() 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) KeyboardInterrupt 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.
judging from the numbers, this does not seem too bad: its around 256MB - do we really have that few RAM on the build slaves?
thunderbird seems to have oom-errors, too - though, they're not in rust, but in /usr/bin/ld.bfd.
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.
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.
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.. :→
Sounds similar: https://github.com/getsentry/sentry-cli/issues/762
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.
dump_syms is a separate package, does rust compilation with –target x86_64-unknown-linux-gnu,
let's fix that one first..
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?
maybe we can simply not do 'mach buildsymbols'? who needs build symbols anyway..
Phoning symbols home?