Malloc bugs exhibited in ports/mail/dovecot

[Jason Evans]

On Jan 16, 2006, at 3:50 AM, <freebsd at newmillennium.net.au> wrote:
> I get core dumps in Dovecot under a recent -CURRENT, Using revision  
> 1.95 of
> malloc.c:
>
> (gdb) bt
> #0  0x0a250642 in arena_new (arena=0xa2d5140, malloced=false,
> recursive=true) at /usr/src/lib/libc/stdlib/malloc.c:3520
> #1  0x0a2520a5 in malloc_init_hard () at
> /usr/src/lib/libc/stdlib/malloc.c:4444
> #2  0x0a251b0e in malloc_init () at /usr/src/lib/libc/stdlib/ 
> malloc.c:4233
> #3  0x0a252222 in malloc (size=32784) at
> /usr/src/lib/libc/stdlib/malloc.c:4528
> #4  0x0805352a in mem_block_alloc (min_size=32768) at data-stack.c:190
> #5  0x080538f5 in data_stack_init () at data-stack.c:360
> #6  0x080575cf in lib_init () at lib.c:24
> #7  0x0804d8f2 in main (argc=1, argv=0xbfbfecd4, envp=0x0) at  
> main.c:281

Are you sure that you were using revision 1.95 of malloc.c?  The  
stacktrace looks more like it is from revsion 1.93.  Can you try  
again with revision 1.95, please?  Revisions 1.93 and 1.94 had a bug,  
in that they didn't check whether an allocation was successful in  
arena_new() before using memset() on the result.  I wouldn't have  
expected the allocation to ever fail, but the stacktrace above  
indicates that dovecot probably crashed as a result of the bug.

If you still have problems with revision 1.95, can you please provide  
details on how to reproduce the crash?

Thanks,
Jason