bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

memory leak in dir-lookup found


From: Marcus Brinkmann
Subject: memory leak in dir-lookup found
Date: Wed, 28 Mar 2001 18:40:40 +0200
User-agent: Mutt/1.3.15i

Hi,

I disabled the vm_deallocate in glibc's init-first, and was able to run the
glibc malloc tracer. (Note that MALLOC_TRACE does only work for the main
thread, after that, debugging info is sent to stdout or so. I started the
translator active and redirected the output).

I get lots of these leaks:
0x08066198      0xc  at 0x10aeebd
0x080661a8      0xc  at 0x10aeebd
0x080661b8      0xc  at 0x10530fd

(and no other reptitives. A lot of "leaks" at startup, and occasionally a new
thread, that's all).

Now, in the actual mtrace output:
@ /lib/libshouldbeinlibc.so.0.2:(make_idvec+0x1d)[0x10aeebd] + 0x805e948 0xc
@ /lib/libshouldbeinlibc.so.0.2:(make_idvec+0x1d)[0x10aeebd] + 0x805e958 0xc
@ /lib/libiohelp.so.0.2:(iohelp_create_iouser+0x1d)[0x10530fd] + 0x805e968 0xc

As we guess this is in dir-lookup, I found the following:
          /* Create an unauthenticated port for DNP, and then
             unlock it. */
          error =
            diskfs_create_protid (diskfs_make_peropen (dnp, 0, dircred->po),
                                  iohelp_create_iouser (make_idvec (),
                                                        make_idvec ()),
                                  &newpi);

Note that we know that this is not a port leak, so the dirport doesn't get
lost. The actual problem happens in conjunction with diskfs_create_protid, which
calls diskfs_finish_protid, which does not consume the iouser, but
duplicates it (see !!! below):

libdiskfs/protid-make.c:

/* Finish building protid CRED started with diskfs_start_protid;
   the user to install is USER. */
void
diskfs_finish_protid (struct protid *cred, struct iouser *user)
{
  if (!user)
    {
      uid_t zero = 0;
      /* Create one for root */
      user = iohelp_create_iouser (make_idvec (), make_idvec ());
      idvec_set_ids (user->uids, &zero, 1);
      idvec_set_ids (user->gids, &zero, 1);
      cred->user = user;
    }
  else
    cred->user = iohelp_dup_iouser (user);          <--------- !!!

  mach_port_move_member (mach_task_self (), cred->pi.port_right,
                         diskfs_port_bucket->portset);
}

There seems to be a similar leak in io-reauthenticate.c, which calls
iohelp_reauth and doesn't free the buffer after finishing the protid. There
are no other callers of diskfs_finish_protid, but there are quite some callers
of diskfs_create_protid, and I will check them for this bug (most seem to use
cred->user, though, which needs to be duplicated).

Obviously the problem with such leaks is that they are only visible by
reading the code if you know the behaviour of all these functions
(which allocate, duplicate, free ressources). Also, some ressources are
handed over to ports and then managed by libport, and should only be freed
in the respective rele function. This can only be solved by more complete
documentation.

I won't even start with the obvious problem that make_idvec and
iohelp_create_iouser both rely on malloc, and nothing here checks the return
values. It will be a long way until the Hurd servers will be able to deal
with out of memory conditions (I am not thinking of dealing well, just of
dealing at all, in the sense to know when it happens rather than getting a
segfault).

A patch will be along the way of:

struct iouser *user;

user = iohelp_create_iouser (make_idvec (), make_idvec ());

          error =
            diskfs_create_protid (diskfs_make_peropen (dnp, 0, dircred->po),
                                  iohelp_create_iouser (make_idvec (),
                                                        make_idvec ()),
                                  &newpi);

iohelp_free_iouser();

The iohelp_free_iouser deals with idvec's.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de



reply via email to

[Prev in Thread] Current Thread [Next in Thread]