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.


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
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to