kr/beanstalkd — pull request #154 by shancat (2012-11-26 12:32:33+00:00)
Title: Fix memory leak.

Compiling with `make CFLAGS-g && make check` then running
`valgrind --leak-check=full --show-reachable=yes ./beanstalkd` and then killing
it reports:
```
HEAP SUMMARY:
in use at exit: 460 bytes in 2 blocks
total heap usage: 7 allocs, 5 frees, 1,136 bytes allocated

4 bytes in 1 blocks are still reachable in loss record 1 of 2
at 0x4027278: malloc (vg_replace_malloc.c:270)
by 0x804BC5F: grow (ms.c:21)
by 0x804BCD2: ms_append (ms.c:33)
by 0x8052ACF: make_and_insert_tube (tube.c:69)
by 0x8052B6D: tube_find_or_make (tube.c:91)
by 0x805196E: prot_init (prot.c:1938)
by 0x8054233: main (main.c:67)

456 bytes in 1 blocks are still reachable in loss record 2 of 2
at 0x4027278: malloc (vg_replace_malloc.c:270)
by 0x8052CD3: zalloc (util.c:78)
by 0x80528B7: make_tube (tube.c:13)
by 0x8052AAC: make_and_insert_tube (tube.c:64)
by 0x8052B6D: tube_find_or_make (tube.c:91)
by 0x805196E: prot_init (prot.c:1938)
by 0x8054233: main (main.c:67)

LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 460 bytes in 2 blocks
suppressed: 0 bytes in 0 blocks
```

This PR fixes the 456 byte leak, compiles and passes all tests. After
`valgrind --leak-check=full --show-reachable=yes ./beanstalkd` reports:
```
HEAP SUMMARY:
in use at exit: 4 bytes in 1 blocks
total heap usage: 7 allocs, 6 frees, 1,136 bytes allocated

4 bytes in 1 blocks are still reachable in loss record 1 of 1
at 0x4027278: malloc (vg_replace_malloc.c:270)
by 0x804BC5F: grow (ms.c:21)
by 0x804BCD2: ms_append (ms.c:33)
by 0x8052AE3: make_and_insert_tube (tube.c:69)
by 0x8052B81: tube_find_or_make (tube.c:91)
by 0x805196E: prot_init (prot.c:1938)
by 0x805424C: main (main.c:69)

LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 4 bytes in 1 blocks
suppressed: 0 bytes in 0 blocks
```

I think the 4 byte leak has something to do with `ms->items` not being freed
properly but I'm not sure. If this PR isn't acceptable I'd be happy to fix it.