Re: Firefox leaks ksems, eventually hitting open file limits

[Jason Thorpe <thorpej%me.com@localhost>]

> On Jun 12, 2020, at 11:53 AM, coypu%sdf.org@localhost wrote:
> 
> netbsd bug.
> 
> cd /usr/tests/kernel
> ktruss -i atf-run t_ksem |grep destroy
> 
> 20341  20341 t_ksem   _ksem_destroy(0x3)          = 0
> tc-start: 1591987770.973495, destroy_on_named
> 14397  14397 t_ksem   _ksem_destroy(0x70403645)   = 0
>       "tc-start: 1591987770.973495, destroy_on_named\n"
> 14594  14594 t_ksem   _ksem_destroy(0x3)          Err#22 EINVAL
> 15753  15753 atf-run  __sigaction_sigtramp(0x7, 0x7f7fff802c30, 0, 0x7a1tc-end: 1591987770.975913, destroy_on_named, passed
>       "tc-end: 1591987770.975913, destroy_on_named, passed\n"

This one is correct ... sem_destroy() is only valid on unnamed semaphores, i.e. those created with sem_init().

> ksem_destroy fails with EINVAL for firefox too, so it leaks.

A possibility here is that Firefox is calling sem_init() in one process and sem_destroy() in another.  That will fail with EINVAL in NetBSD's implementation ... an annoying quirk due to how they're hooked up into the file table.

However, I just re-read the sem_init() spec in 1003.1-2017, and indeed calling sem_destroy() on a pshared semaphore from any process that can access it is allowed.  So, this is probably the bug.

-- thorpej