[Privoxy-devel] more time questions

[Fabian Keil]

Lee <ler762 at gmail.com> wrote:

> On 5/5/16, Fabian Keil <fk at fabiankeil.de> wrote:
> > Lee <ler762 at gmail.com> wrote:
> >  
> >> On 5/3/16, Fabian Keil <fk at fabiankeil.de> wrote:  
> >> > Lee <ler762 at gmail.com> wrote:  
>    [.. snip ..]
> >>
> >> Next set of questions is
> >> - does timegm in miscutil.c leak memory on non-windows systems?
> >>
> >>       old_zone = malloc(3 + strlen(zone) + 1);
> >>          ...
> >> #ifdef _WIN32
> >>          free(old_zone);
> >> #endif /* def _WIN32 */
> >>
> >> Seems like the code should be doing a free regardless of _WIN32 being
> >> defined or not.  
> >
> > POSIX-compliant putenv() implementations add the buffer directly to
> > the environment in which case freeing it while it's in use results in
> > memory corruption.  
> 
> Really!?   That's an .. interesting way to do it.

From FreeBSD's putenv man page:

|     The putenv() function takes an argument of the form ``name=value'' and
|     puts it directly into the current environment, so altering the argument
|     shall change the environment.  If the variable name does not exist in the
|     list, it is inserted with the given value.  If the variable name does
|     exist, it is reset to the given value.
[...]
| HISTORY
| [...]
|     Until FreeBSD 7.0, putenv() would make a copy of string and insert it
|     into the environment using setenv().  This was changed to use string as
|     the memory location of the ``name=value'' pair to follow the POSIX
|     specification.

> > Windows duplicates the buffer content but I'm not aware of other
> > platforms that do this that also rely on the fallback timegm().  
> 
> Implying the GLIBC implementation of timegm doesn't leak memory?

Probably not, at least Valgrind never had any complaints about it.
glibc's timegm() implementation probably also doesn't mess
with the environment.

> I downloaded the code for glibc-2.23 and tried to figure it out, but
> that's going to take more time than I'm willing to spend right now.

Here's the code from FreeBSD's libc:
https://svnweb.freebsd.org/base/head/contrib/tzcode/stdtime/localtime.c?view=markup#l2135

It doesn't mess with the environment either.

> >> - is there a timing window in miscutil.c timegm that can change TZ to
> >> "UTC"?
> >>
> >> Unless each thread get it's own copy of environment variables, it
> >> seems like one thread can do  
> > [...]  
> >> and then the other thread does the putenv / tzset and TZ is
> >> permanently changed to UTC.  
> >
> > I agree that this could happen. The function can probably also
> > temporarily affect timestamps used for log messages.
> >
> > You could try triggering the issues with Privoxy-Regression-Test's
> > --fork option.  
> 
> It took over an hour with --forks 100 and I didn't notice anything
> weird with the date.

Probably an hour isn't enough.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.privoxy.org/pipermail/privoxy-devel/attachments/20160506/b97cf334/attachment.bin>