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, JasonReceived on Mon Jan 16 2006 - 15:43:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:50 UTC