Date: Fri, 23 Jul 2021 20:56:49 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 257314] FBSD 13 crash after some KDE parts crash supposing out of swap space Message-ID: <bug-257314-227-YFqOEU2gwG@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-257314-227@https.bugs.freebsd.org/bugzilla/> References: <bug-257314-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257314 --- Comment #23 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to Michael from comment #20) > all messages I pasted, I copied in original sequence starting with first = occurrence in log Of which exact type of message? If it was a kill message, then it was already too late to see the RAM use around the time just before the kill was done. One of the problems with trying to monitor the system is that, for example, large changes in the amount of attempted memory use (and RAM use) being attempted could occur multiple times per second. But if such happens, it is difficult to observe usefully to even detect that such is the type of context. Some folks try having top running in a loop, sleeping between runs, logging to a file so there is at least a history-sequence (presuming this does not end up killed before the file system updates). A similar point goes for gstat output. But these also end up competing with the paging/swapping activity for I/O resource use. So far as I can tell, the best next evidence that we could get is the patched-in messaging about exactly which condition initiated each kill. The patch does not attempt to prevent the kills or make things work for you, but just reports what condition in the kernel lead to each. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-257314-227-YFqOEU2gwG>