[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proc leaking
From: |
Samuel Thibault |
Subject: |
Re: proc leaking |
Date: |
Sun, 26 Nov 2023 20:32:30 +0100 |
User-agent: |
NeoMutt/20170609 (1.8.3) |
Hello,
Samuel Thibault, le mer. 01 nov. 2023 16:06:57 +0100, a ecrit:
> Samuel Thibault, le mer. 01 nov. 2023 15:35:00 +0100, a ecrit:
> > Samuel Thibault, le mer. 01 nov. 2023 13:14:17 +0100, a ecrit:
> > > Samuel Thibault, le mer. 01 nov. 2023 01:50:40 +0100, a ecrit:
> > > > Samuel Thibault, le mar. 31 oct. 2023 04:40:43 +0100, a ecrit:
> > > > > (it looks like there are memory leaks in proc, its vminfo keeps
> > > > > increasing).
> > > >
> > > > It seems 64bit-specific: the program below makes proc leak memory, 100
> > > > vminfo lines at a time. Possibly __mach_msg_destroy doesn't actually
> > > > properly parse messages to be destroyed, so that in the error case the
> > > > server leaks non-inline data? Flavio, perhaps you have an idea?
> > >
> > > I don't think we have the kernel-to-user equivalent for
> > > adjust_msg_type_size? So that we end up pushing twice too much data to
> > > userland for port arrays?
> >
> > I found and fixed the allocation issue in the kernel.
>
> It seems proc is still leaking, but on the heap this time. This is not
> 64bit-specific, the same simple reproducer triggers it:
>
> while [ "$(echo -n `echo a` )" = a ] ; do : ; done
>
> or more simply:
>
> while true ; do echo $(echo -n $(echo a)) > /dev/null ; done
I found the issue, it's because of the quiescence support in libports,
which assumes that all threads will sooner or later go through a
quiescent state (because it finished processing a message). But that's
not true, proc doesn't set a thread timeout, and thus some threads can
stay indefinitely stuck in receiving messages. And thus the deferred
dereferencing used by ports_destroy_right never gets achieved.
I'll push a fix.
Samuel