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=<optimized out>, s2=<optimized out>, n=<optimized out>) at /usr/src/lib/libc/string/strncmp.c:46 > #1 0x00000008011a9ffe in strncmpeq (nameValue=0x7fffffffeb5e "LC_PAPER=de_DE.UTF-8", name=0x8011be49e "TZ", nameLen=<optimized out>) at /usr/src/lib/libc/stdlib/getenv.c:144 > #2 __findenv_environ (name=<optimized out>, nameLen=<optimized out>) at /usr/src/lib/libc/stdlib/getenv.c:195 > #3 getenv (name=0x8011be49e "TZ") at /usr/src/lib/libc/stdlib/getenv.c:441 > #4 0x0000000801189f49 in tzset_basic (rdlocked=0) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1274 > #5 0x000000080118a13e in localtime (timep=0x801c12030) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1467 > #6 0x000000000040d38d in http_dirlisting (h=0x801c07140, D=0x801c0e080, path=0x7fffffffbb50 "/", arg=0x0) at http.c:214 > #7 0x000000000040ff9d in http_openfile (h=0x801c07140, filename=0x801c0c085 "/", ss=0x7fffffffc108, sockfd=9, nobody=1) at http.c:1485 > #8 0x0000000000413922 in httpresponse (h=0x801c07140, s=9, headerlen=76) at http.c:1940 > #9 0x000000000040657d in handle_read_misc (i=9, h=0x801c07140, ftptimeout_secs=600, nextftp=...) at gatling.c:1051 > #10 0x0000000000404d54 in main (argc=3, argv=0x7fffffffe840, envp=0x7fffffffe860) 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=<optimized out>, s2=<optimized out>, n=<optimized out>) at /usr/src/lib/libc/string/strncmp.c:46 > #1 0x000000080128bb92 in getenv (name=<optimized out>) at /usr/src/lib/libc/stdlib/getenv.c:424 > #2 0x000000080126bb39 in tzset_basic (rdlocked=0) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1281 > #3 0x000000080126bb1b in tzset_basic (rdlocked=-14721152) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1274 > #4 0x000000080122c0a0 in _fmt (format=0x22313031734e6863 <Address 0x22313031734e6863 out of bounds>, t=0x8012a009e, pt=0x2 <Address 0x2 out of bounds>, ptlim=0xf5 <Address 0xf5 out of bounds>, > warnp=0x8014cc418 <tzname+8>, loc=0x80126bb1b <tzset_basic+27>) at /usr/src/lib/libc/stdtime/strftime.c:137 > #5 0x000000080122d6fb in _conv (n=<optimized out>, format=<optimized out>, pt=<optimized out>, n=<optimized out>, format=<optimized out>, pt=<optimized out>, ptlim=<optimized out>) > at /usr/src/lib/libc/stdtime/strftime.c:597 > #6 _yconv (a=<optimized out>, b=<optimized out>, convert_top=<optimized out>, convert_yy=<optimized out>, pt=<optimized out>, ptlim=<optimized out>, a=<optimized out>, b=<optimized out>, > convert_top=<optimized out>, convert_yy=<optimized out>, pt=<optimized out>, ptlim=<optimized out>) at /usr/src/lib/libc/stdtime/strftime.c:649 > #7 0x0000000000428747 in get_log_timestamp (buffer=0x7fffff1f5f80 "2014-06-30 17:03:45.115", buffer_size=30) at errlog.c:482 > [...] > (gdb) f 3 > #3 0x000000080126bb1b in tzset_basic (rdlocked=-14721152) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1274 > 1274 name = 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_at_r500 ~/test/privoxy/test $valgrind gatling -p 81 > ==6563== Memcheck, a memory error detector > ==6563== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. > ==6563== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info > ==6563== Command: gatling -p 81 > ==6563== > starting_up 0 :: 81 > start_ftp 0 :: 2121 > accept 7 10.0.0.1 48596 1 http > ==6563== Invalid read of size 1 > ==6563== at 0x1039C74: strncmp (mc_replace_strmem.c:596) > ==6563== by 0x1BA1FFD: getenv (getenv.c:144) > ==6563== by 0x1B81F48: ??? (localtime.c:1274) > ==6563== by 0x1B8213D: localtime (localtime.c:1467) > ==6563== by 0x40D38C: http_dirlisting (http.c:214) > ==6563== by 0x40FF9C: http_openfile (http.c:1485) > ==6563== by 0x413921: httpresponse (http.c:1940) > ==6563== by 0x40657C: handle_read_misc (gatling.c:1051) > ==6563== by 0x404D53: main (gatling.c:2247) > ==6563== Address 0xff000b7a is not stack'd, malloc'd or (recently) free'd > ==6563== > ==6563== > ==6563== Process terminating with default action of signal 11 (SIGSEGV): dumping core > ==6563== Access not within mapped region at address 0xFF000B7A > ==6563== at 0x1039C74: strncmp (mc_replace_strmem.c:596) > ==6563== by 0x1BA1FFD: getenv (getenv.c:144) > ==6563== by 0x1B81F48: ??? (localtime.c:1274) > ==6563== by 0x1B8213D: localtime (localtime.c:1467) > ==6563== by 0x40D38C: http_dirlisting (http.c:214) > ==6563== by 0x40FF9C: http_openfile (http.c:1485) > ==6563== by 0x413921: httpresponse (http.c:1940) > ==6563== by 0x40657C: handle_read_misc (gatling.c:1051) > ==6563== by 0x404D53: main (gatling.c:2247) > ==6563== If you believe this happened as a result of a stack > ==6563== overflow in your program's main thread (unlikely but > ==6563== possible), you can try to increase the size of the > ==6563== main thread stack using the --main-stacksize= flag. > ==6563== The main thread stack size used in this run was 16777216. > ==6563== > ==6563== HEAP SUMMARY: > ==6563== in use at exit: 18,848 bytes in 6 blocks > ==6563== total heap usage: 25 allocs, 19 frees, 47,144 bytes allocated > ==6563== > ==6563== LEAK SUMMARY: > ==6563== definitely lost: 0 bytes in 0 blocks > ==6563== indirectly lost: 0 bytes in 0 blocks > ==6563== possibly lost: 0 bytes in 0 blocks > ==6563== still reachable: 18,848 bytes in 6 blocks > ==6563== suppressed: 0 bytes in 0 blocks > ==6563== Rerun with --leak-check=full to see details of leaked memory > ==6563== > ==6563== For counts of detected and suppressed errors, rerun with: -v > ==6563== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 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øl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+Received on Thu Jul 03 2014 - 11:30:29 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:50 UTC