Fresh install from source 2023Q2 (i.e. chromium-113.0.5672.126) on 13.2-RELEASE-p1; machine i5-3570T, 8 GM mem chromium fails on practically every page load with "Aw, Snap! Error Code 5". It fails with the same error on chrome://settings/ It does, however, display plain HTML pages correctly. Messages in the terminal: chrome://settings/ <--- Last few GCs ---> [44673:0x1a55086abc80] 183 ms: Mark-Compact (reduce) 1.5 (3.7) -> 1.5 (2.7) MB, 2.37 / 0.00 ms (average mu = 0.020, current mu = 0.020) last resort; GC in old space requested [44673:0x1a55086abc80] 185 ms: Mark-Compact (reduce) 1.5 (2.7) -> 1.5 (2.7) MB, 2.50 / 0.00 ms (average mu = 0.014, current mu = 0.008) last resort; GC in old space requested <--- JS stacktrace ---> [44673:1469513728:0626/125245.139319:ERROR:v8_initializer.cc(752)] V8 javascript OOM (CALL_AND_RETRY_LAST). There should not be any memory constraints in place, and running as root shows the same behaviour. Options : ALSA : off CODECS : on CUPS : on DEBUG : off DRIVER : on HEIMDAL : off HEIMDAL_BASE : on KERBEROS : on LTO : off MIT : off PULSEAUDIO : off SNDIO : on TEST : off Workaround found: $ chrome --js-flags=--lite-mode
Created attachment 244417 [details] v1 (apply via "git am") The crash looks similar to bug 271838, so try the attached patch.
Well are you running with kern.elf64.allow_wx=0 ?
What is your 'ulimit -a' output?
(In reply to Robert Nagy from comment #2) Indeed, kern.elf64.allow_wx=0 is the issue! Thank You! When we got the 'elfctl' tool, some of these issues were patched in the ports tree, then for some others (node, libreoffice) I modified the ports tree only locally - and then forgot about the matter. :(
(In reply to Peter Much from comment #4) Using elfctl won't help you in this case, because there is a bug somewhere probably in the kernel that makes v8 fail even with wxneeded and building anything that uses node (v8) will reqire the -Wl,-z,wxneeded because the build will execute binaries. Anyway I think someone has to look into the issue first, which is probably either fork related or multi-threading related. Using proccontrol just "hides" the issues.