search for: mem_block_alloc

...we recurse until we run totally out of stack. In gdb this looks like repeated calls like this: ... #14507 0x080b22b6 in i_internal_fatal_handler (status=83, fmt=0x0, args=0x76b95d8 "\020") at failures.c:410 #14508 0x080b1e1e in i_fatal_status (status=83, format=0x80cdd64 "mem_block_alloc(): Out of memory when allocating %u bytes") at failures.c:201 #14509 0x080b1652 in mem_block_alloc (min_size=0) at data-stack.c:192 #14510 0x080b1811 in t_malloc_real (size=16, permanent=true) at data-stack.c:244 #14511 0x080b1890 in t_malloc0 (size=16) at data-stack.c:279 #14512 0x080b871...

...e and the backtrace now is: > > --- snip --- > (gdb) bt full > #0? 0x00007f73f1386495 in raise () from /lib64/libc.so.6 > No symbol table info available. > #1? 0x00007f73f1387c75 in abort () from /lib64/libc.so.6 > No symbol table info available. > #2? 0x00007f73f17ab822 in mem_block_alloc (min_size=520) at > data-stack.c:356 > ??????? block = <value optimized out> > ??????? prev_size = <value optimized out> > ??????? alloc_size = 134217728 > #3? 0x00007f73f17abc18 in t_malloc_real (size=<value optimized out>, > permanent=true) at data-stack.c...

On Wed, Jan 24, 2018 at 18:55:47 +0100, Thomas Robers wrote: > Am 23.01.2018 um 20:07 schrieb Josef 'Jeff' Sipek: > > On Tue, Jan 23, 2018 at 14:03:27 -0500, Josef 'Jeff' Sipek wrote: > > > On Tue, Jan 23, 2018 at 18:21:38 +0100, Thomas Robers wrote: ... > > > 1. Do you have any idea what the imap process was doing at the time of the > > >

..._handler (ctx=0x7fff7197d000, format=<optimized out>, args=<optimized out>) at failures.c:670 #4 0x00007fddaf958322 in i_panic (format=format at entry=0x7fddafa047b8 "data stack: Out of memory when allocating %lu bytes") at failures.c:275 #5 0x00007fddaf9bee3f in mem_block_alloc (min_size=536870912) at data-stack.c:341 #6 0x00007fddaf9bf08b in t_malloc_real (size=size at entry=536870912, permanent=permanent at entry=true) at data-stack.c:396 #7 0x00007fddaf9bf0ca in t_malloc (size=size at entry=536870912) at data-stack.c:442 #8 0x00007fddaf9da5f8 in pool_data_stack_r...

...e helpful. I installed the debug package and the backtrace now is: --- snip --- (gdb) bt full #0 0x00007f73f1386495 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x00007f73f1387c75 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x00007f73f17ab822 in mem_block_alloc (min_size=520) at data-stack.c:356 block = <value optimized out> prev_size = <value optimized out> alloc_size = 134217728 #3 0x00007f73f17abc18 in t_malloc_real (size=<value optimized out>, permanent=true) at data-stack.c:415 block = <value...

..._handler (ctx=0x7fff7197d000, format=<optimized out>, args=<optimized out>) at failures.c:670 #4 0x00007fddaf958322 in i_panic (format=format at entry=0x7fddafa047b8 "data stack: Out of memory when allocating %lu bytes") at failures.c:275 #5 0x00007fddaf9bee3f in mem_block_alloc (min_size=536870912) at data-stack.c:341 #6 0x00007fddaf9bf08b in t_malloc_real (size=size at entry=536870912, permanent=permanent at entry=true) at data-stack.c:396 #7 0x00007fddaf9bf0ca in t_malloc (size=size at entry=536870912) at data-stack.c:442 #8 0x00007fddaf9da5f8 in pool_data_stack_r...

Where would I find the core file? I'm not finding anything obvious. The replicator path is /usr/local/libexec/dovecot/replicator Daniel On 3/22/2017 12:52 AM, Aki Tuomi wrote: > Can you provide us gdb bt full dump? > > gdb /usr/libexec/dovecot/replicator /path/to/core > > on some systems, it's /usr/lib/dovecot/replicator > > Aki > > On 21.03.2017 23:48,

I have the following in my log: Mar 21 14:46:59 bubba dovecot: replicator: Panic: data stack: Out of memory when allocating 1073741864 bytes Mar 21 14:46:59 bubba dovecot: replicator: Error: Raw backtrace: /usr/local/lib/dovecot/libdovecot.so.0(+0x97c90) [0x7f4638a7cc90] -> /usr/local/lib/dovecot/libdovecot.so.0(+0x97d6e) [0x7f4638a7cd6e] ->