search for: p_strdup

I did Dovecot profiling on huge e-mail system, and p_strdup was very high on list. I do minor change: p_strdup: /* for (len = 0; (str)[len] != '\0'; ) len++; len++; */ len = strlen(str) + 1; p_strndup: /* len = 0; while (len < max_chars && ((const char *) str)[len] != '\0') len++; */ len = strnlen(str, max_chars); An...

...scape.c". I went deeped and debugged the call to "dict_lookup" performed by doveadm. Indeed the client gets the proper string from the socket and to my surprise, it is properly unescaped. Then, in "client_dict_lookup" ("lib-dict/dict-client.c"), the call to "p_strdup" returns an empty string (null byte set at the target address). Before the call to the dict "->lookup" attribute (client_dict_lookup): RAX: 0x7ffff73a37c0 (push r14) RBX: 0x6831b8 ("priv/reply_body") RCX: 0x7fffffffe240 --> 0x682a60 --> 0x6831b8 (&quot...

...ike a bug, we'll have look. Aki On 17.10.2016 01:26, Pierre Jaury wrote: > I dived a little bit further into the rabbit hole, up to the point where > debugging 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 onl...

...> >>>>>> socket and to my surprise, it is properly unescaped. > > > >>>>>> > > > >>>>>> Then, in "client_dict_lookup" ("lib-dict/dict-client.c"), the call to > > > >>>>>> "p_strdup" returns an empty string (null byte set at the target address). > > > >>>>>> > > > >>>>>> Before the call to the dict "->lookup" attribute (client_dict_lookup): > > > >>>>>> > > > >>&gt...

...ved > >>> but cannot reproduce in that case: > >>> > >>> pool_t pool = pool_datastack_create(); > >>> > >>> char* s1 = "test\001n\001rtest"; > >>> char* s2 = t_str_tabunescape(s1); > >>> char* s3 = p_strdup(pool, s2); > >>> > >>> printf("1>%s\n", s1); > >>> printf("2>%s\n", s2); > >>> printf("3>%s\n", s3); // all three output the string with NL and CR > >>> > >>> Maybe I am missing a fu...

...o the bare minimal string manipulation functions involved > > but cannot reproduce in that case: > > > > pool_t pool = pool_datastack_create(); > > > > char* s1 = "test\001n\001rtest"; > > char* s2 = t_str_tabunescape(s1); > > char* s3 = p_strdup(pool, s2); > > > > printf("1>%s\n", s1); > > printf("2>%s\n", s2); > > printf("3>%s\n", s3); // all three output the string with NL and CR > > > > Maybe I am missing a function call in the process or maybe the issue...

...; // outputs an empty string dict_deinit(&dict); I trimmed it to the bare minimal string manipulation functions involved but cannot reproduce in that case: pool_t pool = pool_datastack_create(); char* s1 = "test\001n\001rtest"; char* s2 = t_str_tabunescape(s1); char* s3 = p_strdup(pool, s2); printf("1>%s\n", s1); printf("2>%s\n", s2); printf("3>%s\n", s3); // all three output the string with NL and CR Maybe I am missing a function call in the process or maybe the issue is related to the way unescaping is performed in the async c...

I am running PC-Pine under Windows XP, connecting via SSL to a Dovecot IMAP server (0.99.10-2 under Debian woody). When I open a mail folder (mbox format) in Pine I get the following non-fatal error: [Junk in end of group: pn=undisclosed-recipients al= dn=] A similar error was reported to comp.mail.pine as happening with a Lotus Domino server. Mark Crispin explained it as a server-side bug:

...e = "(not set)"; diff -ruN src.bak/lib-storage/mailbox-list.c src/lib-storage/mailbox-list.c --- src/lib-storage/mailbox-list.c.bak 2020-03-05 15:35:53.000000000 +0100 +++ src/lib-storage/mailbox-list.c 2020-05-15 22:34:44.329802000 +0200 @@ -173,6 +173,8 @@ list->set.inbox_path = p_strdup(list->pool, set->inbox_path); list->set.subscription_fname = p_strdup(list->pool, set->subscription_fname); + list->set.fallback_driver = + p_strdup(list->pool, set->fallback_driver); list->set.list_index_fname = p_strdup(list->pool, set->list_index_f...

Hi Stephan, Here it is: Program received signal SIGSEGV, Segmentation fault. p_strdup (pool=pool at entry=0x55555579bc20, str=0x6d65642e6c69616d <error: Cannot access memory at address 0x6d65642e6c69616d>) at strfuncs.c:51 51????? strfuncs.c: No such file or directory. (gdb) bt full #0? p_strdup (pool=pool at entry=0x55555579bc20, str=0x6d65642e6c69616d <error: Cannot acc...

...it outputs siglist->sig: ... syslog(LOG_INFO, "working with signature %s ", siglist->sig ); if ((*enh_error = call_dspam (siglist->sig, is_spam))) { ... This leads me to believe that there's a problem with: list_append(listpool, &siglist)->sig = p_strdup(listpool, signature); but I'm really not sure how dovecot deals with allocating pooled memory, as that's what it appears to be doing. I'm not sure what information might be useful to anyone in helping me look into this and the searches i've been able to do have been unsuccessful....

...also have your configuration for me (output from `dovecot -n`) ? > > Also, can you issue in GDB after it crashed (as you did `bt full` > before): > > f 1 > p src > > Regards, > > Stephan. > > >> Program received signal SIGSEGV, Segmentation fault. >> p_strdup (pool=pool at entry=0x55555579bc20, str=0x6d65642e6c69616d >> <error: Cannot access memory at address 0x6d65642e6c69616d>) at >> strfuncs.c:51 >> 51????? strfuncs.c: No such file or directory. >> (gdb) bt full >> #0? p_strdup (pool=pool at entry=0x55555579bc20,...

...xxxxxxxx >> -d test at xxxxxxxxx < message >> process 359 is executing new program: /usr/bin/doveconf >> process 359 is executing new program: /usr/libexec/dovecot/dovecot-lda >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x00007ffff75b74f7 in p_strdup () from /usr/lib/dovecot/libdovecot.so.0 >> (gdb) bt full >> #0? 0x00007ffff75b74f7 in p_strdup () from >> /usr/lib/dovecot/libdovecot.so.0 >> No symbol table info available. >> #1? 0x00007ffff757dd1a in ssl_iostream_settings_init_from () from >> /usr/lib/dovec...

Hi, I came up with the following patch while trying to figure out a good solution for the situation described in Debian bug #871987[1]. In short, OpenSSL in Debian unstable has disabled TLSv1.0 and TLSv1.1 *by default*. That means that unless an application requests otherwise, only TLSv1.2 is supported. In the world of e-mail this is seemingly an issue, as there are still way too many old clients

...program: /usr/libexec/dovecot/dovecot-lda -f root at xxxxxxxx -d test at xxxxxxxxx < message process 359 is executing new program: /usr/bin/doveconf process 359 is executing new program: /usr/libexec/dovecot/dovecot-lda Program received signal SIGSEGV, Segmentation fault. 0x00007ffff75b74f7 in p_strdup () from /usr/lib/dovecot/libdovecot.so.0 (gdb) bt full #0? 0x00007ffff75b74f7 in p_strdup () from /usr/lib/dovecot/libdovecot.so.0 No symbol table info available. #1? 0x00007ffff757dd1a in ssl_iostream_settings_init_from () from /usr/lib/dovecot/libdovecot.so.0 No symbol table info available. #2?...

...ortunity to get debug symbols for Pigeonhole as well. Do you also have your configuration for me (output from `dovecot -n`) ? Also, can you issue in GDB after it crashed (as you did `bt full` before): f 1 p src Regards, Stephan. > Program received signal SIGSEGV, Segmentation fault. > p_strdup (pool=pool at entry=0x55555579bc20, str=0x6d65642e6c69616d > <error: Cannot access memory at address 0x6d65642e6c69616d>) at > strfuncs.c:51 > 51????? strfuncs.c: No such file or directory. > (gdb) bt full > #0? p_strdup (pool=pool at entry=0x55555579bc20, str=0x6d65642e6c696...

I believe that there is one more patch required for a successful build on Tru64: # diff ./src/lib/mountpoint.c.orig ./src/lib/mountpoint.c 60a61,63 > #ifdef __osf__ > point_r->type = p_strdup(pool, getvfsbynumber(buf.f_type)); > #else 62c65,66 < point_r->block_size = buf.f_bsize; --- > #endif > point_r->block_size = buf.f_bsize; Cheers -- Simon L Jackson Carringbush.Net +- Carringbush.Net Hosting * Development * Advice Web: www.carringbush.n...

...auth_request->user = p_strconcat(auth_request->pool, - authenid, "@", - default_realm, NULL); - } else { - auth_request->user = p_strdup(auth_request->pool, - authenid); - } + auth_request->user = p_strdup(auth_request->pool, + t_strcut(authenid, '@')); if (!mech_is_valid_user...

...; in the relevant places). Best Wishes, Chris --- dovecot-1.0-stable/src/lib-mail/message-address.c.orig Fri Apr 8 12:30:34 2005 +++ dovecot-1.0-stable/src/lib-mail/message-address.c Mon Jun 20 10:42:23 2005 @@ -140,6 +140,10 @@ return -1; ctx->addr.name = p_strdup(ctx->pool, str_c(ctx->str)); + if (*ctx->addr.name == '\0') { + /* Cope with "<address>" without display name */ + ctx->addr.name = NULL; + } if (parse_angle_addr(ctx) < 0) { /* broken */...

...'t try to execute the imap process again. Too risky and the wait() call below will break it anyway. Just use the previous capability list we already had generated." I changed the source so that the function always ran " set->imap_generated_capability = p_strdup(settings_pool, generated_capability); return TRUE;" instead of going through the function where it had on the wait described in the comments. Now, voila. Dovecot starts without complaint, the plugin works, the delivery and moving of email works. I'm assuming I've s...