Been staring at this far too long now, so I'll toss it out there and see if someone might be able to lend a hand.

==2579== HEAP SUMMARY:
==2579==     in use at exit: 302,610 bytes in 723 blocks
==2579==   total heap usage: 1,169 allocs, 446 frees, 404,566 bytes allocated
==2579== 
==2579== 20 bytes in 1 blocks are definitely lost in loss record 62 of 159
==2579==    at 0x4024F20: malloc (vg_replace_malloc.c:236)
==2579==    by 0x41124AF: strdup (strdup.c:43)
==2579==    by 0x4E2A18D: ???
==2579==    by 0x418336A: gethostbyaddr_r@@GLIBC_2.1.2 (getXXbyYY_r.c:253)
==2579==    by 0x8065E16: lookup_address (socket.c:1264)
==2579==    by 0x405996D: start_thread (pthread_create.c:300)
==2579==    by 0x416CA4D: clone (clone.S:130)
==2579== 
==2579== LEAK SUMMARY:
==2579==    definitely lost: 20 bytes in 1 blocks
==2579==    indirectly lost: 0 bytes in 0 blocks
==2579==      possibly lost: 0 bytes in 0 blocks
==2579==    still reachable: 302,590 bytes in 722 blocks
==2579==         suppressed: 0 bytes in 0 blocks
==2579== Reachable blocks (those to which a pointer was found) are not shown.
==2579== To see them, rerun with: –leak-check=full –show-reachable=yes

/* does the lookup, changes the hostname, and dies */
void *lookup_address(void *arg)
{
  LOOKUP_DATA *lData = (LOOKUP_DATA *) arg;
  struct hostent *from = 0;
  struct hostent ent;
  char buf[16384];
  int err;

  /* do the lookup and store the result at &from */
  gethostbyaddr_r(lData->buf, sizeof(lData->buf), AF_INET, &ent, buf, 16384, &from, &err);

  /* did we get anything ? */
  if (from && from->h_name)
  {
    free(lData->dsock->hostname);
    lData->dsock->hostname = strdup(from->h_name);
  }

  /* set it ready to be closed or used */
  lData->dsock->lookup_status++;
  
  /* free the lookup data */
  free(lData->buf);
  free(lData);

  /* and kill the thread */
  pthread_exit(0);
}

20 bytes are being lost per function call, which happens to be my hostname (19+1), however, I'm not familiar with gethostbyaddr_r() and google is falling short on letting me know what exactly is being assigned where.

FYI, this is stock SocketMUD 2.4.

Any help would be appreciated… off to bed.

The gethostbyname*() and gethostbyaddr*() functions are obsolete. Applications should use getaddrinfo(3) and getnameinfo(3) instead.

If I'm not mistaken, gethostbyaddr_r() is the thread safe version of gethostbyaddr(). As such, to be thread safe, it MUST allocate memory so that it doesn't overwrite results that a second thread might be using at the same time. Thus, you MUST free the buffer that it allocated after copying the result to your own storage (or remember to free the old one before making a new lookup).

So, obsolete or not, that's why you're losing memory on every call.

Did you verify that using a shorter/longer hostname leads to less/more memory leakage?

I tried everything under the moon to figure out where this extra memory was being allocated but without the proper documentation it was proving to be an incredible hassle. As such I looked up getaddrinfo(3), found some quality information on it, and revamped the _hostname() function. Everything seems to be working fine, and Valgrind seems very happy.

Thanks for the help, appreciate it.

==2010== 60 bytes in 3 blocks are definitely lost in loss record 113 of 188
==2010==    at 0x4024F20: malloc (vg_replace_malloc.c:236)
==2010==    by 0x41124AF: strdup (strdup.c:43)
==2010==    by 0x4E2A18D: ???
==2010==    by 0x418336A: gethostbyaddr_r@@GLIBC_2.1.2 (getXXbyYY_r.c:253)
==2010==    by 0x41885DA: getnameinfo (getnameinfo.c:223)
==2010==    by 0x8064821: lookup_address (mud_socket.c:1313)
==2010==    by 0x405996D: start_thread (pthread_create.c:300)
==2010==    by 0x416CA4D: clone (clone.S:130)

Apparently I didn't fix it.

That being said, I am a little confused. I only suffer from this memory leak while using MUSHclient in WINE(haven't tried MUSHclient in windows). Using KildClient, tintin++ or Mudlet, I suffer no memory leak.

mud_socket.c:1313

error = getnameinfo(res->ai_addr, res->ai_addrlen, hostname, NI_MAXHOST, NULL, 0, 0);

Any guesses?

Edit: GnomeMUD works fine aswell.

Are you using some custom memory model, with your own malloc(), free(), strdup()?…
If so, make it use the original system calls when you're testing your MUD with Valgrind.

The client you are using will have no effect on memory leaks on your server, unless you're doing something exceedingly strange.

Are you running the mud client on the same hardware as the software-server? It's possible it's a leak originating from the mud client if that's the case.

Both the server and client were being run off my laptop last night while I was debugging. I'll do so more tests when I get home by accessing the server from a client on another pc. However, as DH said, I can't imagine why a certain client would cause a memory leak on the server.
When I get home, I'll try some other codebases and see if any similar results happen. I will also try MUSHclient under windows.

i should note too, that my hostname while accessing my server from a client on the same hardware comes back as "my_laptop" except while using MUSHclient in which it comes back "my_laptop.local".

Oh, nevermind. Valgrind wouldn't report the leak in a different application, I thought you were using some other metric.

If some clients make you leak and not other it just means the clients are probably not handling a perticular buffer the same way(like some clients will strip all the whitespace at the end of a string before sending it back, while some other will keep them. It is one explanation, could be others. But you have a leak on your server definitely.

One thought… is it possible that the leak-inducing client is making a second connection to your server for some reason? If may be that you get your leak when something connects, the mud forks a process to do the lookup, and the client disconnects before that finishes?