M_TEMP trouble in 13.0-CURRENT #0 r355131M
Hans Petter Selasky
hps at selasky.org
Thu Jan 9 10:15:06 UTC 2020
On 2020-01-09 11:12, Hans Petter Selasky wrote:
> 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
>> root at 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
I actually see the same (r356321M), but I think it is not harmful:
temp 18446744073709545743 18014398509476107K - 89826
16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536
--HPS
More information about the freebsd-current
mailing list