[Privoxy-devel] PATCH for pcre2 support

[Gagan Sidhu]

whoops i forgot the last line in the pcre1 printout, so to be clear, this is what i’m getting:

pcre2:


> Process 42798 stopped
> * thread #2, stop reason = step over
>    frame #0: 0x000000010000dd12 privoxy`template_fill(template_ptr=0x00000001004005e8, exports=0x0000000100400530) at cgi.c:2040:13
>   2037	   /*
>   2038	    * Assemble pcrs joblist from exports map
>   2039	    */
> -> 2040	   for (m = exports->first; m != NULL; m = m->next)
>   2041	   {
>   2042	      if (*m->name == '$')
>   2043	      {
> Target 0: (privoxy) stopped.
> (lldb) print size
> (size_t) $7 = 1
> (lldb) print strlen(file_buffer)
> error: 'strlen' has unknown return type; cast the call to its declared return type
> (lldb) print (size_t) strlen(file_buffer)
> (size_t) $8 = 15987
> (lldb) print (size_t) strlen(file_buffer) + 1
> (unsigned long) $9 = 15988


pcre1:
> Process 42869 stopped
> * thread #2, stop reason = step over
>     frame #0: 0x000000010000db0f privoxy`template_fill(template_ptr=0x00000001007001b8, exports=0x0000000100700170) at cgi.c:2040:13
>    2037	   /*
>    2038	    * Assemble pcrs joblist from exports map
>    2039	    */
> -> 2040	   for (m = exports->first; m != NULL; m = m->next)
>    2041	   {
>    2042	      if (*m->name == '$')
>    2043	      {
> Target 0: (privoxy) stopped.
> (lldb) print size
> (size_t) $1 = 15988

> (lldb) print strlen(file_buffer)
> error: 'strlen' has unknown return type; cast the call to its declared return type
> (lldb) print (size_t) strlen(file_buffer)
> (size_t) $2 = 15987
> (lldb) print (size_t) strlen(file_buffer) + 1
> (unsigned long) $3 = 15988

Thanks,
Gagan

> On Mar 18, 2023, at 4:02 PM, Gagan Sidhu <broly at mac.com> wrote:
> 
> i am doing some stepping through, and everything looks okay, until we enter template_fill
> 
> from what i’m seeing (and you should check this on your end as well), this “super efficient” approach of using one variable to pass, and later-on store,  the result of pcrs_execute *MAY* be the problem.
> 	
>> int pcrs_execute(pcrs_job *job, const char *subject, size_t subject_length, char **result, size_t *result_length)
> 
> in pcre2:
>> Process 42798 stopped
>> * thread #2, stop reason = step over
>>    frame #0: 0x000000010000dd12 privoxy`template_fill(template_ptr=0x00000001004005e8, exports=0x0000000100400530) at cgi.c:2040:13
>>   2037	   /*
>>   2038	    * Assemble pcrs joblist from exports map
>>   2039	    */
>> -> 2040	   for (m = exports->first; m != NULL; m = m->next)
>>   2041	   {
>>   2042	      if (*m->name == '$')
>>   2043	      {
>> Target 0: (privoxy) stopped.
>> (lldb) print size
>> (size_t) $7 = 1
>> (lldb) print strlen(file_buffer)
>> error: 'strlen' has unknown return type; cast the call to its declared return type
>> (lldb) print (size_t) strlen(file_buffer)
>> (size_t) $8 = 15987
>> (lldb) print (size_t) strlen(file_buffer) + 1
>> (unsigned long) $9 = 15988
> 
> so, for some reason or another, lldb can print the strlen and display it, but the program is not reflecting this.
> 
> in the pcre1 version, no problem at all:
> 
>> Process 42869 stopped
>> * thread #2, stop reason = step over
>>    frame #0: 0x000000010000db0f privoxy`template_fill(template_ptr=0x00000001007001b8, exports=0x0000000100700170) at cgi.c:2040:13
>>   2037	   /*
>>   2038	    * Assemble pcrs joblist from exports map
>>   2039	    */
>> -> 2040	   for (m = exports->first; m != NULL; m = m->next)
>>   2041	   {
>>   2042	      if (*m->name == '$')
>>   2043	      {
>> Target 0: (privoxy) stopped.
> 
> i thank you for sharing your wisdom by immediately going to gdb, reminding me of its great value in these circumstances.
> 
> my proposal going forward:
> 
> 1. please reproduce my findings
> 2. produce a patch that is not “overly-economic” so that subject_length and result_length have their own memory
> 	-it’s possible the optimisations are causing the issue, i’m not sure.
> 
> in theory i don’t see why your approach is problematic for pcre2, this is why i’m thinking it’s some optimisation that clobbers the contents.
> 
> i guess the most important thing is the first step: can you reproduce my findings?
> 	-if you can, then we have found the problem and i think it’s an easy fix.
> 
> whatcha think fabez?
> 
> Thanks,
> Gagan
> 
>