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
3%82;
First of all any idea why cleanup did not segfault with the info rule in
place?
2nd: could such mime headers be the reason for a pcre pattern to let
libpcre segfault?
--
Cheers
tobi
Am 12.05.20 um 15:20 schrieb Wietse Venema:
> Tobi:
>> Hi list
>>
>> we have th
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
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
16 matches
Mail list logo
