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)
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
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
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
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
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
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
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
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
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
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
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]:
15 matches
Mail list logo
