[Privoxy-devel] PATCH for pcre2 support

[Gagan Sidhu]

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