search for: t_malloc0

...(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 'F', format=0x80cdd64 "mem_block_alloc(): Out of memory when alloc...

...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, headers=0xbffff840) at mail-storage.c:376 #12 0x0805e095 in imap_sort (cmd=0x80bb9a8, charset=0x80...

...ll 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 and zeroing it in the process before...

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

...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 and zeroing it in...

...gt; >>> > >>> 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...

...in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x00007f73f17ab822 in ?? () from /usr/lib64/dovecot/libdovecot.so.0 No symbol table info available. #3 0x00007f73f17abc18 in ?? () from /usr/lib64/dovecot/libdovecot.so.0 No symbol table info available. #4 0x00007f73f17abdeb in t_malloc0 () from /usr/lib64/dovecot/libdovecot.so.0 No symbol table info available. #5 0x00007f73f17a95dd in ?? () from /usr/lib64/dovecot/libdovecot.so.0 No symbol table info available. #6 0x00007f73f17a967b in buffer_create_dynamic () from /usr/lib64/dovecot/libdovecot.so.0 No symbol table info availa...

...t;>>>> 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 t...

...6ef in doveadm_cmd_ver2_to_mail_cmd_wrapper (cctx=0x7fffffffe2a0) at doveadm-mail.c:1030 mctx = 0x555555807410 wildcard_user = <optimized out> username_args = {0x5555555b1479 "-u", 0x5555557da298 "anmesse", 0x0} fieldstr = 0x7ffff73d7423 <t_malloc0+35> "H\203\304\bH\211\330[]\303\017\037" username_args_count = <optimized out> i = <optimized out> mail_cmd = {alloc = 0x555555582ad0 <cmd_index_alloc>, name = 0x5555555b3e7b "index", usage_args = 0x5555555b2ee8 "[-u <user>...

...example.com): Error: Raw backtrace: /usr/lib/dovecot/libdovecot.so.0 [0xbd4e70] -> /usr/lib/dovecot/libdoveco t.so.0(default_fatal_handler+0x43) [0xbd4f63] -> /usr/lib/dovecot/libdovecot.so.0 [0xbd4784] -> /usr/lib/dovecot/libdovecot.so.0 [0xbd 241d] -> /usr/lib/dovecot/libdovecot.so.0(t_malloc0+0x29) [0xbd2619] -> /usr/lib/dovecot/libdovecot.so.0(restrict_get_groups_list+0x43 ) [0xbef183] -> /usr/lib/dovecot/libdovecot.so.0 [0xbd2b39] -> /usr/lib/dovecot/libdovecot.so.0 [0xbd2dd2] -> /usr/lib/dovecot/libdove cot.so.0 [0xbd34c6] -> /usr/lib/dovecot/lib10_quota_plugin.so(quot...

..., 0, 0, 0, 0, 0, 0}, __u6_addr32 = {2654464805, 0, 0, 0}}}, ip4 = {s_addr = 2654464805}}}, local_port = 0, remote_port = 0, userdb_fields = 0xf81300ac, flags_override_add = (unknown: 0), flags_override_remove = (unknown: 0), no_userdb_lookup = 0, debug = 0} client = 0xf750331c <t_malloc0+44> flags = <optimized out> error = 0xf8130130 "auth_token=3763fd48bfdfeea2a3617cbda148915c19e125fa" __FUNCTION__ = "login_client_connected" #10 0xf749b0d1 in master_login_auth_finish (client=0xf813b450, auth_args=0xf814d000, auth_args at entry=0...

..._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? 0x00007f73f17a95dd in p_malloc (buf=0x7f73ebdcef28, size=513) at > mempool.h:99 > No locals. > #6? buffer_alloc (buf=0x7f73ebdcef28, size=513) at buffer.c:34 > ??????? __func__ = "buffer_alloc...

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

...8) at cmd-select.c:296 client = 0x7fc7f8a13d30 status = {messages = 4171084000, recent = 32711, unseen = 0, uidvalidity = 0, uidnext = 13, first_unseen_seq = 0, first_recent_uid = 4137782496, last_cached_seq = 32711, highest_modseq = 13, keywords = 0x7fc7f6cd06fb <t_malloc0+43>, permanent_flags = 4171118192, nonpermanent_modseqs = 1, permanent_keywords = 1, allow_new_keywords = 1} flags = MAILBOX_FLAG_DROP_RECENT ret = <optimized out> #20 cmd_select_full (cmd=<optimized out>, readonly=<optimized out>) at cmd-select.c:419 ---Typ...

...timized 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 0x00007f73f17a95dd in p_malloc (buf=0x7f73ebdcef28, size=513) at mempool.h:99 No locals. #6 buffer_alloc (buf=0x7f73ebdcef28, size=513) at buffer.c:34 __func__ = "buffer_alloc" #7 0x00007f73f17a967b...

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: > > Hello, > > > > I'm using Dovecot 2.3 and sometimes i get this: > > > > --- snip --- > > Jan 23 14:23:13 mail dovecot: imap(bob at tutech.de)<4880><PDqibHFjMvrAqG1n>: > > Panic: data stack: Out of