#86 libical messes with timezone, affecting other threads

open
nobody
None
5
2013-07-06
2012-03-12
Fathi Boudra
No

It's a forwarded bug from Debian BTS:
http://bugs.debian.org/630690

icaltime_as_timet_with_zone() sets $TZ before calling libc functions to
do some time calculations. In a multithreaded program that interferes
with other programs which fetch local time, including syslog().

The library shouldn't be messing with the processes' global timezone in this way.

Discussion

  • Allen Winter
    Allen Winter
    2012-03-13

    According to the in-line documention,

    /* If you use set_tz(), you must call unset_tz() some time later to restore the
    original TZ. Pass unset_tz() the string that set_tz() returns. Call both the functions
    locking the tzid mutex as in icaltime_as_timet_with_zone */

    For more information please read icaltime.c in the libical source code.
    Too bad libical doesn't provide real user documentation.

    So I guess you're calling program needs to do some mutex locking.

    Fathi: Please pass this on to the original bug reporter and let me know if I can close this.
    -Allen

     
  • It's worse than that. Any call to setenv() or putenv() in a threaded environment is liable to make other threads crash if they do anything that calls getenv(). And the list of functions which use getenv() is quite long: see http://sourceware.org/bugzilla/show_bug.cgi?id=5069#c9

    If libical uses putenv() or setenv(), then libical is fundamentally unsuitable for use in a threaded environment. It's that simple.

    A patch along these lines should fix it for systems which have timegm().

     
  • Allen Winter
    Allen Winter
    2013-07-06

    Good idea.
    I think what I'll do is copy in a version of the timegm.c to the library so all platforms can have it. then trash set_tz and unset_tz.