[Bug 241848] lib/googletest/gtest/tests: gmock-matchers_test.cc requires a pathological amount of memory to compile
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241848 Dave Evans changed: What|Removed |Added CC||dave.evan...@googlemail.com --- Comment #1 from Dave Evans --- I'm doing a buildworld for amd64 13-CURRENT with FreeBSD 12.1 guest on macOS VirtualBox host with 2.4GB ram assigned to FreeBSD guest. I have 7 GB of swap. The build gets to the Build Everything stage. When it gets to gmock-matchers_test.cc the process is killed with an out of swap signal. swapinfo: Device 1K-blocks UsedAvail Capacity /dev/ada0p2 2097152 11524 2085628 1% /dev/zvol/zroot/swap 5242880 12012 5230868 0% Total 7340032 23536 7316496 0% How much swap does this file need to compile? swapon complains if I try to add more. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243959] Compilation on powerpc fails with __atomic_compare_exchange_8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243959 Bug ID: 243959 Summary: Compilation on powerpc fails with __atomic_compare_exchange_8 Product: Base System Version: 12.1-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: y...@freebsd.org Testcase: net-p2p/libtorrent-rasterbar, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243958 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243959] Compilation on powerpc fails with __atomic_compare_exchange_8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243959 Yuri Victorovich changed: What|Removed |Added Blocks||243958 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243958 [Bug 243958] net-p2p/libtorrent-rasterbar : Fails to build on FreeBSD 12.1-RELEASE-p1 powerpc 32 bit : libtorrent-rasterbar.so.1.2.3: undefined reference to `__atomic_compare_exchange_8' -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 241848] lib/googletest/gtest/tests: gmock-matchers_test.cc requires a pathological amount of memory to compile
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241848 Mark Millard changed: What|Removed |Added CC||marklmi26-f...@yahoo.com --- Comment #2 from Mark Millard --- (In reply to Dave Evans from comment #1) If you get console messages something like (extracted example): . . . kernel: pid 7963 (strip), jid 0, uid 0, was killed: out of swap space This message text's detailed wording is frequently a misnomer. Do you also have any messages of the form: . . . sentinel kernel: swap_pager_getswapspace(32): failed If yes: you really were out of swap space. If no: you were not out of swap space, or at least it is highly unlikely that you were. FreeBSD kills processes for multiple potential reasons. For example: a) Still low on free RAM after a number of tries to increase it above a threshold. b) Slow paging I/O. c) . . . (I do not know the full list) . . . Unfortunately, FreeBSD is not explicit about the category of problem that leads to the kill activity that happens. You might learn more by watching how things are going via top or some such program or other way of monitoring. You likely will find the swap space not low. Below are some notes about specific tunables that might or might not be of help. (There may be more tunables that can help that I do not know about.) For (a) there is a way to test if it is the issue by adding to the number of tries before it gives up and starts killing things. That will either: 1) let it get more done before kills start 2) let it complete before the count is reached 3) make no significant difference (3) would imply that (b) or (c) are involved instead. (1) might be handled by having it do even more tries. For delaying how long free RAM staying low is tolerated, one can increase vm.pageout_oom_seq from 12 to larger. The management of slow paging I've less experience with but do have some notes about below. Examples follow that I use in contexts with sufficient RAM that I do not have to worry about out of swap/page space. These I've set in /etc/sysctl.conf . (Of course, I'm not trying to deliberately run out of RAM.) # # Delay when persisstent low free RAM leads to # Out Of Memory killing of processes: vm.pageout_oom_seq=120 I'll note that figures like 1024 or 1200 or even more are possible. This is controlling how many tries at regaining sufficient free RAM that that level would be tolerated long-term. After that it starts Out Of Memory kills to get some free RAM. No figure is designed to make the delay unbounded. There may be large enough figures to effectively be bounded beyond any reasonable time to wait. As for paging I/O (WARNING: all the below tunables are specific to head (13), or was last I checked): # # For plunty of swap/paging space (will not # run out), avoid pageout delays leading to # Out Of Memory killing of processes: vm.pfault_oom_attempts=-1 (Note: In my context "plunty" really means sufficient RAM that paging is rare. But others have reported on using the -1 in contexts where paging was heavy at times and OOM kills had been happening that were eliminated by the assignment.) I've no experience with the below alternative to that -1 use: # # For possibly insufficient swap/paging space # (might run out), increase the pageout delay # that leads to Out Of Memory killing of # processes: #vm.pfault_oom_attempts= ??? #vm.pfault_oom_wait= ??? # (The multiplication is the total but there # are other potential tradoffs in the factors # multiplied, even for nearly the same total.) I'm not claiming that these 3 vm.???_oom_??? figures are always sufficient. Nor am I claiming that tunables are always available that would be sufficient. Nor that it is easy to find the ones that do exist that might help for specific OOM kill issues. I have seen reports of OOM kills for other reasons when both vm.pageout_oom_seq and vm.pfault_oom_attempts=-1 were in use. As I understand, FreeBSD did not report what kind of condition lead to the decision to do an OOM kill. So the above notes may or may-not help you. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 241848] lib/googletest/gtest/tests: gmock-matchers_test.cc requires a pathological amount of memory to compile
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241848 --- Comment #3 from Robert Clausecker --- These notes aside: this memory usage is far from the norm for compiling a C++ source file. I believe there must be a bug in clang or llvm or some unfortunate design in the source file itself that causes this memory usage. This is more than twice the highest memory usage I observed before (roughly 800 MB for one of the X86 instruction selection files in the LLVM source) and as opposed to that case, there is no apparent explanation for the memory usage. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 241848] lib/googletest/gtest/tests: gmock-matchers_test.cc requires a pathological amount of memory to compile
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241848 --- Comment #4 from Mark Millard --- (In reply to Mark Millard from comment #2) I should have noted: if a process stays runnable, FreeBSD does not stop it and swap it out but instead just pages it. (For FreeBSD, swapping basically seems to mean that the kernel stacks were also moved out to swap space and would have to be brought back in for the process to run.) Thus, 1 or more processes that use large amounts of memory relative to the RAM size but also stay runnable, are not not stopped and swapped out to make room. In such a context, if free RAM stays low, despite other efforts to gain some back, processses are then killed instead. vm.pageout_oom_seq controls how many attempts are made to gain more free RAM before the kills start. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 241848] lib/googletest/gtest/tests: gmock-matchers_test.cc requires a pathological amount of memory to compile
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241848 --- Comment #5 from Mark Millard --- (In reply to Dave Evans from comment #1) Was this a -j1 build? Something larger? (There could be other things worth reporting about the build context.) It can be interesting to watch the system with top sorted by resident RAM use (decreasing). It can give a clue what are the major things contributing to low free RAM while watching. I'm not sure one can infer much from which process FreeBSD decides to kill. Other evidence is likely better about what is contributing to the sustained low free RAM that likely is what leaded to the process kill(s). To Robert: I've been replying mostly to Dave because it has been a significant time since I've experimented with a 1 GiByte machine for buildworld buildkernel and the like. Dave indicated over 2 GiByte for his context. You could try vm.pageout_oom_seq=1200 and a -j1 build and see if it helps you. Reporting the result here might be useful. Actually, you indicated "upgrade to FreeBSD 12.1", so your context is appearently older, such as 12.0. I'm not sure if vm.pageout_oom_seq goes back that far. That might leave you only with -j1 (which, for all I know, you might have already been using). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 241437] objcopy --add-section doesn't work
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241437 --- Comment #2 from Ed Maste --- See https://reviews.freebsd.org/D23571 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 241848] lib/googletest/gtest/tests: gmock-matchers_test.cc requires a pathological amount of memory to compile
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241848 --- Comment #6 from Mark Millard --- (In reply to Mark Millard from comment #5) Looks like vm.pageout_oom_seq goes back to 10.3.0-RELEASE so experiments with it on a 12.0-RELEASE based system should be possible. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243972] Missing word "be" in rc.conf(5) "hostname" section
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243972 Bug ID: 243972 Summary: Missing word "be" in rc.conf(5) "hostname" section Product: Documentation Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Manual Pages Assignee: b...@freebsd.org Reporter: paua...@gundo.com CC: d...@freebsd.org > Within a > .Xr jail 8 > the hostname is generally already set and this variable may absent. s/may/may be/ -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243973] [zfs] zfs rollback segmentation fault
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243973 Bug ID: 243973 Summary: [zfs] zfs rollback segmentation fault Product: Base System Version: 12.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: reshadpatu...@gmail.com Created attachment 211466 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=211466&action=edit ZFS core file (xz compressed) I have a FreeBSD 12.1 system running zfs as root (default zfs install) + pkg base installed (all 318 packages). While I was testing the rollback of a system update using the 'zfs rollback' command after 'pkg upgrade -f' and I noticed that zfs rollback for 'zroot/ROOT/default@pre-update' is segfaulting. Strangely if I run the same command again after sleeping for 10 seconds it works flawlessly every time. Here is the backtrace for the segmentation fault from the core file. - (gdb) backtrace #0 0x0008004a7e4a in pthread_rwlock_unlock_exp (p0=0x6) at /usr/src/lib/libc/gen/_pthread_stubs.c:249 #1 0x00080029402e in zcmd_ioctl (fd=6, request=25, zc=0x6) at /usr/src/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_compat.c:113 #2 0x000800292374 in lzc_ioctl (ioc=3222821401, name=, source=, resultp=0x7fffdc40) at /usr/src/cddl/contrib/opensolaris/lib/libzfs_core/common/libzfs_core.c:187 #3 0x000800293492 in lzc_rollback_to (fsname=0xc0185a19 , snapname=) at /usr/src/cddl/contrib/opensolaris/lib/libzfs_core/common/libzfs_core.c:869 #4 0x0008002dc381 in zfs_rollback (zhp=0x800839280, snap=, force=) at /usr/src/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c:4194 #5 0x0020e2a1 in zfs_do_rollback (argc=, argv=0x7fffeb18) at /usr/src/cddl/contrib/opensolaris/cmd/zfs/zfs_main.c:3574 #6 0x0020c6a4 in main (argc=, argv=0x7fffeb10) at /usr/src/cddl/contrib/opensolaris/cmd/zfs/zfs_main.c:7507 (gdb) - I have attached the zfs.core file along with the shell script to reproduce the segmentation fault. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243973] [zfs] zfs rollback segmentation fault
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243973 --- Comment #1 from Reshad Patuck --- Created attachment 211467 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=211467&action=edit Shell script to reproduce the segfault This shell script reproduces the issue 100% of the time for me -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243973] [zfs] rollback segmentation fault
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243973 Kubilay Kocak changed: What|Removed |Added Flags||mfc-stable12?, ||mfc-stable11? Summary|[zfs] zfs rollback |[zfs] rollback segmentation |segmentation fault |fault Keywords||crash, needs-qa Status|New |Open CC||zfs-de...@freebsd.org Assignee|b...@freebsd.org|zfs-de...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
