Samuel Thibault, le mar. 31 oct. 2023 04:40:43 +0100, a ecrit:
> Samuel Thibault, le lun. 30 oct. 2023 18:35:03 +0100, a ecrit:
> > Samuel Thibault, le dim. 29 oct. 2023 23:27:22 +0100, a ecrit:
> > > Samuel Thibault, le ven. 27 oct. 2023 08:48:19 +0200, a ecrit:
> > > > while [  "$(echo -n `echo  internal/reflectlite.s-gox | sed -e 
> > > > 's/s-gox/gox/' ` )" = internal/reflectlite.gox ] ; do : ; done
> > > 
> > > For now, I could reproduce with
> > > 
> > > time while [  "$(echo -n `echo a` )" = a ] ; do : ; done
> > > 
> > > by running two of them in parallel, along with an apt install loop in
> > > parallel. It takes a few hours to reproduce (sometimes 1, sometimes
> > > 3...)
> > 
> > It seems to happen more often when running inside a chroot (possibly
> > because of the intermediate firmlink redirection?), and possibly
> > eatmydata also makes it more frequent.
> 
> (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?

Samuel


#include <hurd.h>
#include <stdio.h>

#define N 1024
int main(void) {
        mach_port_t port = getproc();
        mach_port_t ports[N];
        int ints[N];
        for (int i = 0; i < N; i++) {
                ports[i] = MACH_PORT_DEAD;
        }
        for (int i = 0; i < 100; i++) {
                int ret = proc_setexecdata(port, ports, 
MACH_MSG_TYPE_COPY_SEND, N, ints, N);
                if (ret) {
                        errno = ret;
                        perror("setexecdata");
                }
        }
        return 0;
}

Reply via email to