On 26/07/17(Wed) 13:13, Mark Kettenis wrote: > > Date: Wed, 26 Jul 2017 12:11:31 +0200 > > From: Martin Pieuchot <m...@openbsd.org> > > > > On 24/07/17(Mon) 23:41, Laurence Tratt wrote: > > > On Sun, Jul 23, 2017 at 11:32:06PM +0100, Laurence Tratt wrote: > > > > > > > extsmaild (http://tratt.net/laurie/src/extsmail/) appears to be > > > > causing > > > > the final panic, but given that it's just in a "wake every 60 > > > > seconds > > > > and see if new files have appeared in a directory" loop, I'm not > > > > sure > > > > why. > > > > > > I've now triggered another crash, this time without extsmaild (or Iridium) > > > running. The trace is here: > > > > > > https://imagebin.ca/v/3UWOneXfuSWQ > > > > > > The "culprit" process is now mutt, but the panic is still "out of space in > > > kmem_map" and the trace seems to be in ufs_readdir. > > > > I have seen the same panic message while watching a movie fullscreen > > with mplayer yesterday. > > > > However as soon as CPU0 tried to enter DDB, after typing mach ddbcpu 0, > > the machine freeze. > > Sounds like something is leaking memory. I don't really see any > evidence of this on my systems. The main consumer of kmem_map "space" > (on amd64) is malloc(9). Does vmstat -m give any clues about what is > consuming/leaking memory?
The only "leak" I'm seeing is the 'drmreq' pool. It grows until the application is closed. Note that with my fix the allocated size for 'drmreq' is divided by 4. So if that was the problem I might not be able to reproduce it.
