On Tue, May 14, 2019 at 9:24 PM Bob Bishop <r...@gid.co.uk> wrote: > > On 14 May 2019, at 07:50, Andriy Gapon <a...@freebsd.org> wrote: > > In the end, it was POSIX shared memory. > > I put the system into the single-user to clean up the memory as much as > > possible > > and then I panic'ed it and went through dirty pages and their related > > objects in > > kgdb. As far as I can tell, the memory was leaked via POSIX shared memory > > objects that were never shm_unlink-ed. It seems that there was a > > misbehaving > > program that had been creating such objects and then losing track of them. > > (I > > was able to identify it from names it used for the objects) > > > > It seems that, unfortunately, there is no way to list / discover POSIX > > shared > > memory objects that are not opened by any process. > > Losing track of shared memory objects has been a problem since SysVr2 ... > > > I wrote a small gdb script to examine shm_dictionary in kgdb. It would be > > nice > > to have a utility (and a kernel interface) that could do the same from > > userland. > > ... it is indeed high time it was fixed.
Hello, Newbie hacker here. Here are some things I've noticed while working (fairly heavily) with POSIX shm: 1. As mentioned, you can't list 'em (unlike Linux, where you can just ls /dev/shm). There's a TODO note, but it's not clear whether it's best to extend ipcs or create a new userspace tool, and it wasn't immediately clear to me how to feed the arbitrary sized results back to userspace. I had a scheme worked out where you'd keep calling a sysctl repeatedly to collect the data until it was done, and it'd sometimes tell you you need a bigger buffer (because you probably have to drain at least a whole hash table bucket at a time), but an experienced FreeBSD hacker told me that was BS, and maybe what's needed is a device you read. As well as the list-all-the-segments tool, you'd also want to be able to unlink to tidy up. 2. procstat -v doesn't show the paths of POSIX shm objects that are mapped in (unlike the Linux equivalent, where they're treated as mapped files). That's quite useful to me when developing. I have a draft patch somewhere that fixes that, though I hadn't got around to dealing with jail prefixes sensibly. 3. The hash table is of fixed size and has one simple lock. Maybe this is not really a problem for anyone yet, I don't know. Perhaps the locking should be made more granular to reduce contention from the list-all-the-segments thing that needs to loop over it. 4. I'm suspicious of the way jailing is implemented; I haven't tested but I suspect that jails leak all their POSIX shm when they shut down, but then if you start a new jail at the same path it can be accessed again. _______________________________________________ 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"
