[Privoxy-devel] PATCH for pcre2 support

Gagan Sidhu broly at mac.com
Sun Jun 18 16:06:37 CEST 2023


i should also mention that, while you may be correct that we use pcrs_execute in a loop in template_fill, the (now fixed) issue appeared immediately.

that is, even before the first iteration was completed, the second argument and fourth argument were already garbled. so it didn’t take “looping” for me to discover the problem.

this was why tests didn’t even start. 

i was thinking it’s possible that this was happening in pcrs_execute_single_command, as well.

you may be right that it’s due to the looping, but if i saw the issue right away on the first iteration, it’s possible this obliteration is happening here, as well.

Thanks,
Gagan

> On Jun 18, 2023, at 8:01 AM, Gagan Sidhu <broly at mac.com> wrote:
> 
> have you tried with optimisations disabled just to rule that out?
> 
> the error below isn’t telling us much, in my opinion.
> 
> it tells it fails in rewrite_url but not where exactly in that function (if i am reading it correctly?)
> 
> could you also add this case to the regression tests or show me how i can feed this to privoxy in no-daemon mode to assist ?
> 
> Thanks,
> Gagan
> 
>> On Jun 18, 2023, at 7:54 AM, Fabian Keil <fk at fabiankeil.de <mailto:fk at fabiankeil.de>> wrote:
>> 
>> Gagan Sidhu <broly at mac.com <mailto:broly at mac.com>> wrote on 2023-06-18 at 07:05:21:
>> 
>>> sorry for the second response, but i think i found the other issue.
>>> 
>>> in rewrite_url, it’s calling pcrs_execute_single_command,
>>> which calls pcrs_execute exactly as template_fill did (with
>>> the same variable for the buffer size and result size).
>>> 
>>> i have updated the patch to use the same solution you’ve provided earlier in this exchange.
>> 
>> Thanks for the update.
>> 
>> In pcrs_execute_single_command() pcrs_execute() isn't called
>> in a loop, though, so the update of buffer_size doesn't seem
>> needed as the variable isn't read later on.
>> 
>>> 32d4ba607ab45ee3970c3e5912943bef6192067c517fda26ae4bf18dc0a94119
>>> 
>>> this should fix the problem you’ve shown below, in case the
>>> conditional for pcre2_jit_compile was not the problem.
>> 
>> I've tested with the latest patch
>> (f690d18e858c844de3caf2db2a8acbd70ecabc34d7f288f5d986eae01d1e7de6)
>> and it still results in the crash in rewrite_url():
>> 
>> (gdb) where
>> #0  kill () at kill.S:4
>> #1  0x00000008008926e0 in __fail (msg=0x80079c824 "stack overflow detected; terminated") at /usr/src/lib/libc/secure/stack_protector.c:130
>> #2  0x0000000800892650 in __stack_chk_fail () at /usr/src/lib/libc/secure/stack_protector.c:137
>> #3  0x000000000024abed in rewrite_url (old_url=0x801e7b280 "https://slashdot.org/story/23/06/18/0332230/what-happens-when-you-ask-alexa-if-amazon-is-a-monopoly?utm_source=rss1.0mainlinkanon&utm_medium=feed <https://slashdot.org/story/23/06/18/0332230/what-happens-when-you-ask-alexa-if-amazon-is-a-monopoly?utm_source=rss1.0mainlinkanon&utm_medium=feed>", 
>>    pcrs_command=0x801a00180 "s@\\?(utm_source=rss1.0)?(mainlinkanon)?&utm_medium=feed@@") at filters.c:1038
>> #4  0x000000000024acf7 in redirect_url (csp=0x800ef1008) at filters.c:1257
>> #5  0x00000000002583b5 in crunch_response_triggered (csp=0x800ef1008, crunchers=0x218920 <crunchers_all>) at jcc.c:953
>> #6  0x00000000002569d6 in chat (csp=0x800ef1008) at jcc.c:4482
>> #7  0x0000000000255736 in serve (csp=0x800ef1008) at jcc.c:5056
>> #8  0x000000080073ca7a in thread_start (curthread=0x800e12700) at /usr/src/lib/libthr/thread/thr_create.c:292
>> #9  0x0000000000000000 in ?? ()
>> Backtrace stopped: Cannot access memory at address 0x7fffdfffe000
>> 
>> Fabian
>> _______________________________________________
>> Privoxy-devel mailing list
>> Privoxy-devel at lists.privoxy.org <mailto:Privoxy-devel at lists.privoxy.org>
>> https://lists.privoxy.org/mailman/listinfo/privoxy-devel
> 



More information about the Privoxy-devel mailing list