Tobi:
> Wietse,
>
> Am 14.05.20 um 16:04 schrieb Wietse Venema:
> > So your best bet is to rewrite your patterns.
>
> that's what we did now and it saves a lot of cpu cycles :-) As our
> pattern matched something at beginning and at the end of the string (all
> stuff between matched via patterns
Wietse,
Am 14.05.20 um 16:04 schrieb Wietse Venema:
> So your best bet is to rewrite your patterns.
that's what we did now and it saves a lot of cpu cycles :-) As our
pattern matched something at beginning and at the end of the string (all
stuff between matched via patterns with * repetition) the
On Thu, May 14, 2020 at 02:38:09PM -0400, Wietse Venema wrote:
> Viktor Dukhovni:
> > Alternatively, we could siglongjmp() out of a segfault handler, enabled
> > around PCRE lookups, leaking whatever heap space libpcre may have
> > allocated along the way, and log a more informative message, and t
Viktor Dukhovni:
> Alternatively, we could siglongjmp() out of a segfault handler, enabled
> around PCRE lookups, leaking whatever heap space libpcre may have
> allocated along the way, and log a more informative message, and thereby
> perhaps even avoid occasional service throttling in master that
On Thu, May 14, 2020 at 01:40:23PM -0400, Wietse Venema wrote:
> > A cursory glance at the PCRE2 docs suggests that we can ask libpcre
> > to enforce more conservative limits before it runs out of stack, and
> > it would presumably then unwind and return a recoverable error.
>
> That looks like a
Viktor Dukhovni:
> On Thu, May 14, 2020 at 10:04:44AM -0400, Wietse Venema wrote:
>
> > Once a program runs out of stack space, that is is an unrecoverable
> > error.
>
> A cursory glance at the PCRE2 docs suggests that we can ask libpcre
> to enforce more conservative limits before it runs out o
On Thu, May 14, 2020 at 10:04:44AM -0400, Wietse Venema wrote:
> Once a program runs out of stack space, that is is an unrecoverable
> error.
A cursory glance at the PCRE2 docs suggests that we can ask libpcre
to enforce more conservative limits before it runs out of stack, and
it would presumabl
Tobi:
> So the problem is definitely our pattern in combination with a VERY big
> mime part header. We're on introducing limits where we can in our patterns.
> Anyway I think that this should not end in such an ugly error where
> postfix cleanup goes south because of such header/pattern combination
Tobi:
> Hi Wietse
>
> using your suggestion with valgrind I found that the main-stacksize
> seems to be the problem. By using --main-stacksize with different values
> I found that the last working value is 59449345, changing to ...344 let
> postmap segfault:
>
> > valgrind -s --main-stacksize=594
Wietse, Viktor
It seems that this is the problematic part of the pcre pattern
>
/^Content-(Disposition|Type).*name\s*=\s*("(?:[^"]|\\")*|[^();:,\/<>\@\"?=<>\[\]\
]*)
I tested by replacing star by star with explicit limits and found that
limits avoid the segfault. I replaced the last two stars wi
On Thu, May 14, 2020 at 08:53:42AM +0200, Tobi wrote:
> using your suggestion with valgrind I found that the main-stacksize
> seems to be the problem. By using --main-stacksize with different values
> I found that the last working value is 59449345, changing to ...344 let
> postmap segfault:
But
Hi Wietse
using your suggestion with valgrind I found that the main-stacksize
seems to be the problem. By using --main-stacksize with different values
I found that the last working value is 59449345, changing to ...344 let
postmap segfault:
> valgrind -s --main-stacksize=59449344 --tool=memcheck
Tobi:
> Hi
>
> as usual: thanks to Wietse :-)
>
> Adding the info rule to the pcre maps solved more than expected. After
> adding the info rule postfix cleanup did not segfault anymore and the
> mail could be accepted --> we have the source now.
> From what I see that is a massively oversized mim
Hi
as usual: thanks to Wietse :-)
Adding the info rule to the pcre maps solved more than expected. After
adding the info rule postfix cleanup did not segfault anymore and the
mail could be accepted --> we have the source now.
From what I see that is a massively oversized mime part header. I
count
Tobi:
> Hi list
>
> we have the very rare problem that cleanup "triggers" segfaults in
> libpcre. We're currently running postfix 3.5.1 but had the issue before
> updating (with postfix 3.4.4) as well. OS is a Centos7 with latest updates.
>
> > May 12 14:36:14 XXX kernel: cleanup[23927]: segfault
Hi list
we have the very rare problem that cleanup "triggers" segfaults in
libpcre. We're currently running postfix 3.5.1 but had the issue before
updating (with postfix 3.4.4) as well. OS is a Centos7 with latest updates.
> May 12 14:36:14 XXX kernel: cleanup[23927]: segfault at 7ffc5118ef78
> i
16 matches
Mail list logo
