Re: getenv("TZ") crashes triggered by tzset_basic()

On Thu, 3 Jul 2014 14:01+0200, Fabian Keil wrote:

> Using HEAD, www/gatling reproducible crashes for me after receiving
> a single request if TZ isn't set:
> =

> (gdb) where
> #0  strncmp (s1=3D<optimized out>, s2=3D<optimized out>, n=3D<optimized o=
ut>) at /usr/src/lib/libc/string/strncmp.c:46
> #1  0x00000008011a9ffe in strncmpeq (nameValue=3D0x7fffffffeb5e "LC_PAPER=
=3Dde_DE.UTF-8", name=3D0x8011be49e "TZ", nameLen=3D<optimized out>) at /us=
r/src/lib/libc/stdlib/getenv.c:144
> #2  __findenv_environ (name=3D<optimized out>, nameLen=3D<optimized out>)=
 at /usr/src/lib/libc/stdlib/getenv.c:195
> #3  getenv (name=3D0x8011be49e "TZ") at /usr/src/lib/libc/stdlib/getenv.c=
:441
> #4  0x0000000801189f49 in tzset_basic (rdlocked=3D0) at /usr/src/lib/libc=
/../../contrib/tzcode/stdtime/localtime.c:1274
> #5  0x000000080118a13e in localtime (timep=3D0x801c12030) at /usr/src/lib=
/libc/../../contrib/tzcode/stdtime/localtime.c:1467
> #6  0x000000000040d38d in http_dirlisting (h=3D0x801c07140, D=3D0x801c0e0=
80, path=3D0x7fffffffbb50 "/", arg=3D0x0) at http.c:214
> #7  0x000000000040ff9d in http_openfile (h=3D0x801c07140, filename=3D0x80=
1c0c085 "/", ss=3D0x7fffffffc108, sockfd=3D9, nobody=3D1) at http.c:1485
> #8  0x0000000000413922 in httpresponse (h=3D0x801c07140, s=3D9, headerlen=
=3D76) at http.c:1940
> #9  0x000000000040657d in handle_read_misc (i=3D9, h=3D0x801c07140, ftpti=
meout_secs=3D600, nextftp=3D...) at gatling.c:1051
> #10 0x0000000000404d54 in main (argc=3D3, argv=3D0x7fffffffe840, envp=3D0=
x7fffffffe860) at gatling.c:2247
> =

> This is not a recent regression, I first noticed it a couple
> of months ago but haven't had time to look into it yet.
> =

> If was reminded of this because a program I'm working on
> (Privoxy) recently crashed thusly:
> =

> (gdb) where
> #0  0x000000080128ef40 in strncmp (s1=3D<optimized out>, s2=3D<optimized =
out>, n=3D<optimized out>) at /usr/src/lib/libc/string/strncmp.c:46
> #1  0x000000080128bb92 in getenv (name=3D<optimized out>) at /usr/src/lib=
/libc/stdlib/getenv.c:424
> #2  0x000000080126bb39 in tzset_basic (rdlocked=3D0) at /usr/src/lib/libc=
/../../contrib/tzcode/stdtime/localtime.c:1281
> #3  0x000000080126bb1b in tzset_basic (rdlocked=3D-14721152) at /usr/src/=
lib/libc/../../contrib/tzcode/stdtime/localtime.c:1274
> #4  0x000000080122c0a0 in _fmt (format=3D0x22313031734e6863 <Address 0x22=
313031734e6863 out of bounds>, t=3D0x8012a009e, pt=3D0x2 <Address 0x2 out o=
f bounds>, ptlim=3D0xf5 <Address 0xf5 out of bounds>, =

>     warnp=3D0x8014cc418 <tzname+8>, loc=3D0x80126bb1b <tzset_basic+27>) a=
t /usr/src/lib/libc/stdtime/strftime.c:137
> #5  0x000000080122d6fb in _conv (n=3D<optimized out>, format=3D<optimized=
 out>, pt=3D<optimized out>, n=3D<optimized out>, format=3D<optimized out>,=
 pt=3D<optimized out>, ptlim=3D<optimized out>)
>     at /usr/src/lib/libc/stdtime/strftime.c:597
> #6  _yconv (a=3D<optimized out>, b=3D<optimized out>, convert_top=3D<opti=
mized out>, convert_yy=3D<optimized out>, pt=3D<optimized out>, ptlim=3D<op=
timized out>, a=3D<optimized out>, b=3D<optimized out>, =

>     convert_top=3D<optimized out>, convert_yy=3D<optimized out>, pt=3D<op=
timized out>, ptlim=3D<optimized out>) at /usr/src/lib/libc/stdtime/strftim=
e.c:649
> #7  0x0000000000428747 in get_log_timestamp (buffer=3D0x7fffff1f5f80 "201=
4-06-30 17:03:45.115", buffer_size=3D30) at errlog.c:482
> [...]
> (gdb) f 3
> #3  0x000000080126bb1b in tzset_basic (rdlocked=3D-14721152) at /usr/src/=
lib/libc/../../contrib/tzcode/stdtime/localtime.c:1274

> 1274		name =3D getenv("TZ");

Does the code test at all for the possibility of getenv(3) returning a =

NULL pointer?

> I haven't been able to reproduce the Privoxy crash yet, but in case
> of gatling the problem is reproducible and valgrind doesn't complain
> about any previous memory corruption:
> =

> fk@r500 ~/test/privoxy/test $valgrind gatling -p 81
> =3D=3D6563=3D=3D Memcheck, a memory error detector
> =3D=3D6563=3D=3D Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward=
 et al.
> =3D=3D6563=3D=3D Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyr=
ight info
> =3D=3D6563=3D=3D Command: gatling -p 81
> =3D=3D6563=3D=3D =

> starting_up 0 :: 81
> start_ftp 0 :: 2121
> accept 7 10.0.0.1 48596 1 http
> =3D=3D6563=3D=3D Invalid read of size 1
> =3D=3D6563=3D=3D    at 0x1039C74: strncmp (mc_replace_strmem.c:596)
> =3D=3D6563=3D=3D    by 0x1BA1FFD: getenv (getenv.c:144)
> =3D=3D6563=3D=3D    by 0x1B81F48: ??? (localtime.c:1274)
> =3D=3D6563=3D=3D    by 0x1B8213D: localtime (localtime.c:1467)
> =3D=3D6563=3D=3D    by 0x40D38C: http_dirlisting (http.c:214)
> =3D=3D6563=3D=3D    by 0x40FF9C: http_openfile (http.c:1485)
> =3D=3D6563=3D=3D    by 0x413921: httpresponse (http.c:1940)
> =3D=3D6563=3D=3D    by 0x40657C: handle_read_misc (gatling.c:1051)
> =3D=3D6563=3D=3D    by 0x404D53: main (gatling.c:2247)
> =3D=3D6563=3D=3D  Address 0xff000b7a is not stack'd, malloc'd or (recentl=
y) free'd
> =3D=3D6563=3D=3D =

> =3D=3D6563=3D=3D =

> =3D=3D6563=3D=3D Process terminating with default action of signal 11 (SI=
GSEGV): dumping core
> =3D=3D6563=3D=3D  Access not within mapped region at address 0xFF000B7A
> =3D=3D6563=3D=3D    at 0x1039C74: strncmp (mc_replace_strmem.c:596)
> =3D=3D6563=3D=3D    by 0x1BA1FFD: getenv (getenv.c:144)
> =3D=3D6563=3D=3D    by 0x1B81F48: ??? (localtime.c:1274)
> =3D=3D6563=3D=3D    by 0x1B8213D: localtime (localtime.c:1467)
> =3D=3D6563=3D=3D    by 0x40D38C: http_dirlisting (http.c:214)
> =3D=3D6563=3D=3D    by 0x40FF9C: http_openfile (http.c:1485)
> =3D=3D6563=3D=3D    by 0x413921: httpresponse (http.c:1940)
> =3D=3D6563=3D=3D    by 0x40657C: handle_read_misc (gatling.c:1051)
> =3D=3D6563=3D=3D    by 0x404D53: main (gatling.c:2247)
> =3D=3D6563=3D=3D  If you believe this happened as a result of a stack
> =3D=3D6563=3D=3D  overflow in your program's main thread (unlikely but
> =3D=3D6563=3D=3D  possible), you can try to increase the size of the
> =3D=3D6563=3D=3D  main thread stack using the --main-stacksize=3D flag.
> =3D=3D6563=3D=3D  The main thread stack size used in this run was 1677721=
6.
> =3D=3D6563=3D=3D =

> =3D=3D6563=3D=3D HEAP SUMMARY:
> =3D=3D6563=3D=3D     in use at exit: 18,848 bytes in 6 blocks
> =3D=3D6563=3D=3D   total heap usage: 25 allocs, 19 frees, 47,144 bytes al=
located
> =3D=3D6563=3D=3D =

> =3D=3D6563=3D=3D LEAK SUMMARY:
> =3D=3D6563=3D=3D    definitely lost: 0 bytes in 0 blocks
> =3D=3D6563=3D=3D    indirectly lost: 0 bytes in 0 blocks
> =3D=3D6563=3D=3D      possibly lost: 0 bytes in 0 blocks
> =3D=3D6563=3D=3D    still reachable: 18,848 bytes in 6 blocks
> =3D=3D6563=3D=3D         suppressed: 0 bytes in 0 blocks
> =3D=3D6563=3D=3D Rerun with --leak-check=3Dfull to see details of leaked =
memory
> =3D=3D6563=3D=3D =

> =3D=3D6563=3D=3D For counts of detected and suppressed errors, rerun with=
: -v
> =3D=3D6563=3D=3D ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 f=
rom 0)
> Segmentation fault
> =

> I can't reproduce the problem with a test program that merely calls
> localtime(), so I assume some environment changes are required.
> =

> Has anyone seens this or is able to reproduce the gatling crashes?
> =

> Fabian
> =


-- =

+-------------------------------+------------------------------------+
| Vennlig hilsen,               | Best regards,                      |
| Trond Endrest=F8l,              | Trond Endrest=F8l,                   |
| IT-ansvarlig,                 | System administrator,              |
| Fagskolen Innlandet,          | Gj=F8vik Technical College, Norway,  |
| tlf. mob.   [phone],       | Cellular...: [phone],       |
| sentralbord 61 14 54 00.      | Switchboard: [phone].      |
+-------------------------------+------------------------------------+
_______________________________________________
[e-mail] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[e-mail]"