search for: t_malloc_real

...libc.so.6 #6 0x080985ba in i_internal_panic_handler ( fmt=0x6 <Address 0x6 out of bounds>, args=0xd14 <Address 0xd14 out of bounds>) at failures.c:374 #7 0x080989d4 in i_panic (format=0x80add1b "Trying to allocate %u bytes") at failures.c:173 #8 0x08097e37 in t_malloc_real (size=Variable "size" is not available. ) at data-stack.c:214 #9 0x08097f54 in t_malloc0 (size=0) at data-stack.c:282 #10 0x08074d34 in index_header_lookup_init (box=0x80c2990, headers=0xbffff840) at index-mail-headers.c:622 #11 0x0808c6f1 in mailbox_header_lookup_init (box=0x0, hea...

...rgs=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 0x080b8715 in pool_datastack_create () at mempool-datastack.c:51 #14513 0x080bda2b in t_str_new (initial_size=512) at str.c:17 #14514 0x080b21f3 in internal_handler (log_type=70 ...

...[New process 7474] #0 0x00007fc4c0ff37f3 in t_malloc_real (size=512, permanent=false) at data-stack.c:306 306 data-stack.c: No such file or directory....

...ugging has become unpracticle but I still haven't found the root > cause for sure. > > I read most of the code for "p_strdup" based on datastack memory pools > (which are used for dictionary lookups both with doveadm and by extdata) > and it seems ok. Still, after "t_malloc_real" is called in "t_malloc0", > the allocated buffer has the same address as the source string. > > The only sensible explanation I can come up with is that during > unescaping, strings are not allocated properly, leading to the memory > pool reusing the string address an...

....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 optimized out> > ??????? ret = <value optimized out> > ??????? alloc_size = 520 > #4? 0x00007f73f17abdeb in t_malloc0 (size=513) at data-stack.c:468 > ??????? mem = &...

Hello, I am using a dict proxy for my sieve extdata plugin to access some fields from an SQLite database (autoreply text and other database-configured items). All tests are performed against version 2.2.25. $ dovecot --version 2.2.25 (7be1766) My configuration looks like: dict { sieve = sqlite:/etc/dovecot/pigeonhole-sieve.dict } [...] sieve_extdata_dict_uri = proxy::sieve I

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 > > >

...practicle but I still haven't found the root >> cause for sure. >> >> I read most of the code for "p_strdup" based on datastack memory pools >> (which are used for dictionary lookups both with doveadm and by extdata) >> and it seems ok. Still, after "t_malloc_real" is called in "t_malloc0", >> the allocated buffer has the same address as the source string. >> >> The only sensible explanation I can come up with is that during >> unescaping, strings are not allocated properly, leading to the memory >> pool reusing t...

...oot > >>> cause for sure. > >>> > >>> I read most of the code for "p_strdup" based on datastack memory pools > >>> (which are used for dictionary lookups both with doveadm and by extdata) > >>> and it seems ok. Still, after "t_malloc_real" is called in "t_malloc0", > >>> the allocated buffer has the same address as the source string. > >>> > >>> The only sensible explanation I can come up with is that during > >>> unescaping, strings are not allocated properly, leading t...

...gt;) 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_realloc (pool=<optimized out>, mem=0x7fdd99f59038, old_size=268435449, new_s...

...7c75 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 optimized out> ret = <value optimized out> alloc_size = 520 #4 0x00007f73f17abdeb in t_malloc0 (size=513) at data-stack.c:468 mem = <value optimized out> #5...

...flags = MAILBOX_FLAG_DROP_RECENT ret = <optimized out> #16 cmd_select_full (cmd=cmd at entry=0xb9305b50, readonly=readonly at entry=false) at cmd-select.c:435 client = 0xb93050e8 ctx = <optimized out> args = 0xb9308380 list_args = 0xb75d5bcc <t_malloc_real+12> mailbox = 0xb92dd240 "virtual/Lists/Dovecot" error = 0xb74e5f25 <__memset_sse2+37> "\201\303\033\331\003" __FUNCTION__ = "cmd_select_full" #17 0xb77911a7 in cmd_select (cmd=0xb9305b50) at cmd-select.c:444 No locals. #18 0xb779682a i...

...gt;) 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_realloc (pool=<optimized out>, mem=0x7fdd99f59038, old_size=268435449, new_s...

...sure. > >>>>> > >>>>> I read most of the code for "p_strdup" based on datastack memory pools > >>>>> (which are used for dictionary lookups both with doveadm and by extdata) > >>>>> and it seems ok. Still, after "t_malloc_real" is called in "t_malloc0", > >>>>> the allocated buffer has the same address as the source string. > >>>>> > >>>>> The only sensible explanation I can come up with is that during > >>>>> unescaping, strings are n...

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] ->