On 2020-01-09 10:59, Poul-Henning Kamp wrote:
I noticed yesterday that M_TEMP stats are screwed up, and rebooted my
laptop for reasons of safety.

However, it's back again now:

     critter phk> vmstat -m | grep temp
     temp 18446744073709546036 18014398509476380K       -   963239  
16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536

FreeBSD critter.freebsd.dk 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r355131M: Wed 
Nov 27 16:44:48 UTC 2019     
r...@critter.freebsd.dk:/usr/obj/freebsd/src/amd64.amd64/sys/GENERIC-NODEBUG  
amd64

I mentioned this on IRC yesterday and noted I had a "disk full" on
a tmpfs mount, but that can now be disregarded as a false lead.

On this kernel I have had an instance where X got killed for
out-of-swap, at a time where that certainly should not have been
the case.

Am I the only one seeing this ?


Hi,

2**64 - 18446744073709546036
ans =  6144

Someone likely freed to M_TEMP which were not supposed to free there.

You could use dtrace to narrow this down and you can also add a kdb_backtrace() for the first couple of users of free() when the stats is negative.

Else:

grep -r M_TEMP /usr/src/sys

And do an audit.

--HPS
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to