[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Firefox leaks ksems, eventually hitting open file limits
> 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.
Main Index |
Thread Index |