grossd 0.9.3 leaks memory

Found it with mdb (Solaris modular debugger):

$ gcore `pgrep grossd` ; telnet smtp01 5522
gcore: core.7787 dumped
Trying 10.10.13.1...
Connected to smtp01.mess.utu.fi.
Escape character is '^]'.
0: Grossd OK. Update queue: 61 (In: 61 + Out: 0) Trust: 465 Match: 13 Greylist: 
404
Block: 4016 Queries/sec: 2.029838 Dnsbl matches: grossd dnsbl matches
(bl.spamcop.net, dnsbl.njabl.org, dnsbl.sorbs.net, dnsbl-1.uceprotect.net,
dnsbl-2.uceprotect.net, dnsbl-3.uceprotect.net, rbl-plus.mail-abuse.org,
zen.spamhaus.org): 1229, 47, 1275, 2054, 2324, 2258, 1552, 3232
Connection to smtp01.mess.utu.fi closed by foreign host.
$ mdb core.7787 
Loading modules: [ libumem.so.1 libc.so.1 libthread.so.1 ld.so.1 ]
> ::findleaks
mdb: couldn't read ptr at fd000000 (size 27271168); rval is -1: no mapping for 
address
CACHE     LEAKED   BUFCTL CALLER
00074288       1 00090168 Malloc+0x50
00074288    4603 000a96f8 libc.so.1`strdup+0xc
00074288       8 000901e0 libc.so.1`strdup+0xc
00074508     275 000e0f00 libc.so.1`strdup+0xc
----------------------------------------------------------------------
   Total    4887 buffers, 80392 bytes
> 000901e0$<bufctl_audit
0x901e0:        next            addr            slab
                23c7f8          8bfc0           85f80           
0x901ec:        cache           timestamp       thread
                74288           660987782521611251               
0x901fc:        lastlog         contents        stackdepth
                58b54           0               8               
                libumem.so.1`umem_cache_alloc+0x13c
                libumem.so.1`umem_alloc+0x44
                libumem.so.1`malloc+0x2c
                libc.so.1`strdup+0xc
                namevalueparams+0x21c
                read_config+0xfc
                main+0x3ec      
                _start+0x108    
> 000e0f00$<bufctl_audit
0xe0f00:        next            addr            slab
                0               ddf50           85dd0           
0xe0f0c:        cache           timestamp       thread
                74a08           66098783600474537b               
0xe0f1c:        lastlog         contents        stackdepth
                6f9c8           0               10              
                libumem.so.1`umem_cache_alloc+0x13c
                libumem.so.1`umem_alloc+0x44
                libumem.so.1`malloc+0x2c
                libc.so.1`strdup+0xc
                try_match+0x50  
                process_parameter+0x13c
                parsequery+0x90 
                sjsms_connection+0x248
                thread_pool+0x7a0
                libthread.so.1`_lwp_start
> 000a96f8$<bufctl_audit
0xa96f8:        next            addr            slab
                0               a5ec0           85ef0           
0xa9704:        cache           timestamp       thread
                74c88           66098783895076037b               
0xa9714:        lastlog         contents        stackdepth
                63644           0               10              
                libumem.so.1`umem_cache_alloc+0x208
                libumem.so.1`umem_alloc+0x44
                libumem.so.1`malloc+0x2c
                libc.so.1`strdup+0xc
                try_match+0x50  
                process_parameter+0x13c
                parsequery+0x90 
                sjsms_connection+0x248
                thread_pool+0x7a0
                libthread.so.1`_lwp_start

It seems that a buffer per query gets lost. The only buffer that has been added 
to
the code lately is the helo string with strdup(). There is no matching Free() in
request_unlink().

Fixed in next patch release.
Original comment by eino.tuominen@gmail.com on 20 Apr 2008 at 1:01
Changed state: Fixed
einot / gross

grossd 0.9.3 leaks memory #59
