This will be fixed on next release, 2.2.26. We won't backport it to
latest stable, sorry.
Aki
On 18.10.2016 15:36, Pierre Jaury wrote:
> Hello,
>
> I can confirm the issue is fixed. Do you have a policy to backport the
> patch at least to the latest stable?
>
> Regards,
>
> On 10/17/2016 11:45 P
Hello,
I can confirm the issue is fixed. Do you have a policy to backport the
patch at least to the latest stable?
Regards,
On 10/17/2016 11:45 PM, Aki Tuomi wrote:
> On 10/16/2016 11:16 PM, Pierre Jaury wrote:
>> Hello,
>>
>> I am using a dict proxy for my sieve
> > > > On 10/16/2016 11:16 PM, Pierre Jaury wrote:
> > > >> 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).
> > > >>
> > >
Sorry, sent the wrong version, please see amended one attached.
Aki
> On October 17, 2016 at 10:18 PM Aki Tuomi wrote:
>
>
> Oh duh, it used datastack pool. Try again with the attached patch? Please
> remember to clear the previous one out before trying.
>
> Aki
>
> >
> > The trace is miss
Oh duh, it used datastack pool. Try again with the attached patch? Please
remember to clear the previous one out before trying.
Aki
>
> The trace is missing some symbols, I will debug tomorrow and see where
> the call comes from exactly.
>
> Regards,
>
>
> On 10/17/2016 06:23 PM, Aki Tuomi w
Thanks for your help, indeed duplicating the result sounds cleaner than
duplicating before escaping. However, you patch still fails, when
allocating in "pool_data_stack_malloc" this time. I get the following
stack trace:
Panic: pool_data_stack_malloc(): stack frame changed
Error: Raw backtrace: /u
Hi!
Looking at the code, I think the bug is that it just copies pointer to the
value, it should, instead, duplicate the value to some memory region. Can you
see if this following patch fixes it?
Aki
> On October 17, 2016 at 4:14 PM Pierre Jaury wrote:
>
>
> Okay, it seems to me that the bug
While trying to isolate properly and reproduce, I was able to trigger
the same bug with the following code:
struct dict *dict;
char* dict_uri = "proxy::sieve";
char* key = "priv/key";
char* username = "ad...@domain.tld";
char* value, error;
dict_drivers_register_builtin();
dict_init
Okay, it seems to me that the bug is due to "t_str_tabunescape" using
the unsafe datastack ("t_strdup_noconst") while the string is actually
returned in an async callback.
Before it is handled by "client_dict_lookup", "client_dict_wait"
actually fires some IO loops that are more than likely to cal
Hi!
This does sound like 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_str
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 {
siev
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 extdat
12 matches
Mail list logo
