The computer keeps crashing during the compilation process of chromium-123.0.6312.58_1, but never crashed when I was building version 123.0.6312.58!

O

Oleg_NYC

Hi! For some reason, poudriere really hates chromium-123.0.6312.58_1, even though only yesterday, I succeeded in building the earlier version of chromium: 123.0.6312.58. "sysctl hw.ncpu" equals 20 on my computer, so yesterday, I had MAKE_JOBS_NUMBER=20 in my /usr/local/etc/poudriere.d/make.conf and ALLOW_MAKE_JOBS=yes with USE_TMPFS="wrkdir data localbase" in my /usr/local/etc/poudriere.conf. With these settings, I finished building version 123.0.6312.58 after poudriere spent almost 3 hours on the compilation process. But there is something about version 123.0.6312.58_1 that poudriere really hates! My computer keeps crashing during its compilation process. Even when I changed the value of MAKE_JOBS_NUMBER to 4 and changed the value of USE_TMPFS to either no or "data", my computer kept crashing every time I was compiling version 123.0.6312.58_1! Can you please explain to me the cause of this problem? As you can see, even when MAKE_JOBS_NUMBER's value was 4, I failed to build version _1, while yesterday I built version 123.0.6312.58 with value 20. This is so bizarre.
 
"crashing" :p

The _1 at the end tends to indicate a patch... can someone please post that patch and log commentary? It looks like the patch was applied, but ended up breaking something.

And that's on top of the unresolved and undefined matter of the "crashing".
 
lang/rust: Bump revisions after 1.77.0
Code: 
diff --git a/www/chromium/Makefile b/www/chromium/Makefile
index fcc944af7cc0..f14d1f3676b7 100644
--- a/www/chromium/Makefile
+++ b/www/chromium/Makefile
@@ -1,5 +1,6 @@
PORTNAME= chromium
PORTVERSION= 123.0.6312.58
+PORTREVISION= 1
CATEGORIES= www wayland
Rust has been updated from 1.76.0 to 1.77.0.
Chromium is unchanged.
 
Ha! It's very strange, but I think I figured out the cause of the crash. Today, instead of typing "poudriere bulk -j 14amd64 www/chromium", I typed "poudriere bulk -j 14amd64 -vvv www/chromium". So, because of this -vvv thing, my computer crashes a couple of minutes after poudriere starts the compilation process. I have gdb installed, but when the computer reboots due to the crash, the /var/crash directory remains empty. This is so strange. Why would -vvv (which is simply additional logging information) crash the computer and not leave any information about the crash in /var/crash?
 
No, it's not encrypted. My swap partition is 15GB in size, so I don't know why the crash info didn't get dumped. Forgive me if I seem like a n00b to you. Right now I am truly puzzled by the fact that yesterday I succeeded in compiling chromium using the settings that I mentioned in my first post, and today I keep crashing despite using very conservative settings that were also mentioned in the first post. Maybe it sounds silly, but is it possible that -vvv, which is simply there to produce additional logging information, somehow contributes to the crash? Well, I need to solve the mystery of why the crash info doesn't end up in /var/crash to try to answer this... I am very confused now. Yesterday, I was compiling chromium while i915kms wasn't loaded. (It was always loaded today). Maybe it sounds silly, but is it possible that yesterday, I succeeded in compiling chromium because that module wasn't loaded? It's more like a rhetorical question because you probably can't answer that without additional info. Well... I am going to continue trying to figure out the cause of it...
 
cracauer@ said:
And we are puzzled by you still not saying what exactly happens when you say "crash".
Click to expand...
After chromium finishes configuring itself (as displayed by poudriere's "configure" message), it starts building itself (as displayed by poudriere's "build" message). A few minutes after the compilation process starts, I see the message on the screen "panic: privileged instruction fault" or "panic: page fault" and the computer reboots. Core.txt.0 never gets created and saved into /var/crash. What I don't understand is why I wasn't having this issue yesterday! As I said in my first post, yesterday, I was building chromium (the version that preceded _1) and this compilation process was running for almost 3 hours before it successfully concluded. In my first post, I told you about the contents of my make.conf and poudriere.conf. I keep saying that for some mysterious reason, despite using exactly the same settings that I had used earlier (MAKE_JOBS_NUMBER=20 and USE_TMPFS="wrkdir data localbase"), the computer kept crashing every time I tried to build version _1. I started tweaking the settings (changing 20 to 4, etc.), but the computer kept crashing. I am at a loss... Why does this problem exist now, despite not existing earlier?..
 
Who knows. But your hardware is not stable.

You really should have told us earlier that you are getting proper panics with different messages.
 
I erased the hard drive, installed FreeBSD 15-CURRENT on it, and compiled more than 300 packages with poudriere before it started compiling chromium. In my poudriere.conf, I had ALLOW_MAKE_JOBS=yes, USE_TMPFS="wrkdir data localbase", PARALLEL_JOBS=1, and in my poudriere.d/make.conf, I had
Code: 
.if ${.CURDIR:M*/www/chromium}
MAKE_JOBS_NUMBER=20
.else
MAKE_JOBS_NUMBER=8
.endif
So, with these settings, I compiled more than 300 packages, but during the compilation process of chromium itself, the computer crashed ("double fault", "privileged instruction fault", or "page fault" panics after I made a few attempts to compile chromium using these settings). The crashes happened after poudriere spent around 20 minutes of compiling chromium. (The same crashing outcome happened after I changed the setting to USE_TMPFS=no and also made sure that make.conf consisted of only one line that said MAKE_JOBS_NUMBER=8). Then I edited the configuration file to make it say #ALLOW_MAKE_JOBS=yes (yes, I commented it out). I also commented out the only line that make.conf had. So, now poudriere has been compiling chromium for more than 2 hours and 40 minutes and the computer hasn't crashed yet. I don't know if I should stop the compilation process and run a hardware diagnostics tool that is (hopefully) available in the computer's UEFI...
 
Nah, you don't want some nonsense BIOS tool. memtest86+, superpi, mprime is where the hardware testing game is at.

I would do that rather sooner than later as harddrive contents can get scrambled pretty quickly when there is memory corruption.
 
Maybe you should clean some fans and tell powerdxx to throttle at maybe 70 °C.

Not getting crash dumps may be due to the location of your swap. It is only done when you swap to a partition, not a vdev or even a file
 
powerdxx_enable="YES" and powerdxx_flags="-H 70:70" in /etc/rc.conf? Okay... Let me try that... By the way, can setting vm.pageout_oom_seq to some value help me in this situation? According to my understanding, vm.pageout_oom_seq is helpful when there is not enough RAM and swapping is required. This machine has 64 GB of RAM, by the way. As I said in my first post,
Code: 
 sysctl hw.ncpu
outputs 20.
 
That, or a brown out (P4 and ISA bus roms, anyone?), or a race when too many cores clamour for the same resource, or a voltage glitch from power demand spiking... Many things are possible.

The CPU will force a hard stop before it catches fire when the temperature sensor on die tell it to. Not when things start to act up.
 
"powerdxx_flags="-H 70:70" had to be replaced with "powerdxx_flags="-H 69:70" because powerd++ refused to start. I also had to disable the Speed Shift technology in the UEFI; before I did it, powerd++ had refused to start. I resumed the previously stopped compilation process of chromium; and more than an hour later, the process is still running using the old settings (20 make jobs and TMPFS="wrkdir data localbase".) However, during the previous compilation process that was utilizing just 1 job, ccache was running. Is it possible I should thank ccache, not powerd++, for the fact that the current compilation process is still running? The current process used previously built object files that ccache had saved, right? I don't know; maybe I am saying something silly... So, I take it, vm.pageout_oom_seq is needed for totally different situations, not the one I ended up in?
 
Alain De Vos said:
For me from ports chromium builds fine with "MAKE_JOBS_UNSAFE=yes".
It only tooks 24hours to build.
Click to expand...
With as many default settings as possible, right? The point of ports is to be able to tweak them so that the software has useful features turned on. If you're not gonna tweak the defaults, then maybe pre-compiled packages are not a bad idea.
 
It took poudriere six hours to compile chromium, so it looks like powerd++ drastically reduced the clock speeds of the cpu cores. Two days ago, when I was using exactly the same settings (20 make jobs, tmpfs="wrkdir localbase data"), it took a bit less than 3 hours to compile chromium. I took a look at the man page for powerd++, so I wonder what will happen if I do this: powerdxx_flags="-H 69:70 -a max" .

Crivens said:
looks like it could really be overheating. Proof would be to kill the cache and retry.
Click to expand...

What do you mean? "killall -9 ccache" and then "poudriere bulk -j 15amd64 <some_port>"? But if ccache is mentioned in poudriere.conf, it will start up again after poudriere starts up, won't it?
 
Yes, but you can go into the ccache storage directory and "rm" the lot. Maybe tgz it before that, I have no idea how much time went into building it up.

And you can increase the temperature setting. Seventy is set in my laptop, as I don't want it to be too hot. Maybe you can get away with 120/140/... Or you monitor the core temperature when building without the powerdxx limit and cut 20% off? There is some speculation and try& error, or maybe you simply need to clean the fans and some new thermal paste?
 
You must log in or register to reply here.
Back
Top