#518 Segfault on encode-universal-time on Windows binary

segfault
closed-fixed
Sam Steingold
clisp (525)
5
2009-06-16
2009-05-06
TY C
No

I'm using the pre-built Windows binary as shown below.

C:\Program Files\clisp-2.47>clisp.exe --version
GNU CLISP 2.47 (2008-10-23) (built on stnt067 [192.168.0.1])
Software: GNU C 3.4.5 (mingw-vista special r3)
gcc -mno-cygwin -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-ty
pe -Wmissing-declarations -Wno-sign-compare -O2 -fexpensive-optimizations -falig
n-functions=4 -D_WIN32 -DUNICODE -DDYNAMIC_FFI -I. -x none -lintl -lreadline -lt
ermcap -lavcall -lcallback -luser32 -lws2_32 -lole32 -loleaut32 -luuid -liconv -
lsigsegv
SAFETY=0 HEAPCODES STANDARD_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRI
VIALMAP_MEMORY
libsigsegv 2.6
libiconv 1.11
libreadline 5.2
Features:
(READLINE REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP
LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI
GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 WIN32)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: C:\Program Files\clisp-2.47\ User language: ENGLISH
Machine: PC/386 (PC/?86) mb6596_chewyong.lvl.local [10.6.91.29]

C:\Program Files\clisp-2.47>

When trying the following, dates near or before 1 Jan 1970 cause segfaults.

[1]> (encode-universal-time 0 0 0 1 1 2009)
3439710000
[2]> (encode-universal-time 0 0 0 2 1 1970)
2209028400
[3]> (encode-universal-time 0 0 1 1 1 1970)

*** - handle_fault error2 ! address = 0x0 not in [0x19d90000,0x19f2d920) !
SIGSEGV cannot be cured. Fault address = 0x0.
GC count: 3
Space collected by GC: 0 1422192
Run time: 0 2500000
Real time: 0 353756792
GC time: 0 156250
Permanently allocated: 93984 bytes.
Currently in use: 2783908 bytes.
Free space: 469794 bytes.

The closest I got was about here:

[6]> (encode-universal-time 0 0 13 1 1 1970)
2208988800
[7]> (encode-universal-time 0 30 12 1 1 1970)

*** - handle_fault error2 ! address = 0x0 not in [0x19d90000,0x19f12efc) !
SIGSEGV cannot be cured. Fault address = 0x0.
GC count: 0
Space collected by GC: 0 0
Run time: 0 781250
Real time: 0 353913045
GC time: 0 0
Permanently allocated: 92384 bytes.
Currently in use: 2249892 bytes.
Free space: 452233 bytes.

It seems anything previous to that also segfaults.

Not sure if time zone/daylight savings is important, but I'm at NZST +12hrs.

An older cygwin version (own build) of clisp-2.41 runs all the above just fine.

Discussion

  • Sam Steingold
    Sam Steingold
    2009-05-06

    works for me in NYC, clisp-2.47-win32-mingw-big.exe, windows server 2003 r2sp2
    what is your windows version?

     
  • TY C
    TY C
    2009-05-07

    My installer was indeed the same:

    clisp-2.47-win32-mingw-big.exe

    Under My Computer->Properties, I get

    Microsoft Windows XP
    Professional
    Version 2002
    Service Pack 3

    Intel(R)
    Pentium(R) 4 CPU 3.00GHz
    3.00 GHz, 1.98 GB of RAM
    Physical Address Extension

    I tried to look through an old copy of the clisp sources I had (around
    v2.41). After placing format at various places in encode-universal-time
    (in defs1.lisp) I managed to narrow it down to

    system::default-time-zone.

    The smallest value before this segfaults is 613621, so this 'just'
    segfaults for me.

    (system::default-time-zone 613620 nil)

    Looking in LISPFUNNR(default_time_zone,2) (time.d), it looks like
    daylight savings is not checked for any dates prior to 613608
    (1/1/1970 I believe). This is also 12 (hrs) away from the segfaulting
    613620. I refer to the following snippet:

    else if (R_minusp(arg)
    || (posfixnump(arg) && (posfixnum_to_V(arg) < 613608))) {
    now = 0; /* < 1.1.1970 -> treat like 1.1.1970 */

    Looking at seconds_west, I couldn't figure what could go wrong with
    now = 0... so this is as far as I can investigate today. Wished clisp
    had more parts implemented in Lisp itself, for introspection.

     
  • Sam Steingold
    Sam Steingold
    2009-05-07

    do you have a c compiler and debugger (e.g., cygwin/mingw come with gcc and gdb)?
    it would be nice if you could build a debuggable version of clisp.

    I have a conjecture that the actual crash happens in seconds_west, when it calls localtime and gmtime.
    can you try in C
    time_t now = (time_t)(613620 - 613608) * 3600;
    gmtime(now);
    localtime(now);
    and see if it crashes?
    thanks!

     
  • TY C
    TY C
    2009-05-08

    > can you try in C
    > time_t now = (time_t)(613620 - 613608) * 3600;
    > gmtime(now);
    > localtime(now);

    Perhaps you meant &now in the args to gmtime and localtime.

    And yes, you're right. I've found the bug, and it's nearby at
    *(localtime(&now)). I missed it yesterday because I was using my
    Cygwin setup (installed Mingw today).

    Here's a good example, main4.c:

    #include <time.h>

    int main(){
    time_t now = (time_t) -1;
    printf("HI\n");
    printf("%d\n", localtime(&now));
    printf("%d\n", gmtime(&now));
    }

    Using Mingw, we can see that 'localtime' returns a NULL pointer:
    C:\home\code\c\localtime>c:/mingw/bin/gcc main4.c

    C:\home\code\c\localtime>a
    HI
    0
    0

    On Cygwin:
    $ gcc main4.c

    $ ./a.exe
    HI
    1628725432
    1628725432

    Another (non-critical?) inconsistency is in the daylight savings
    calculations. Copy,pasting & modifying time.d's code, see attached
    source file main5.c

    Using Mingw:

    C:\home\code\c\localtime>a
    == 1 ==
    == 2 ==
    Done. 0, -13, -780, -46800, 1
    == 3 ==

    On Cygwin:

    $ ./a.exe
    == 1 ==
    == 2 ==
    Done. 0, -12, -720, -43200, 0
    == 3 ==

     
  • TY C
    TY C
    2009-05-08

     
    Attachments
  • Sam Steingold
    Sam Steingold
    2009-05-08

    please try resetting your computer's timezone to, say, EST or GMT - does it still segfault?

     
  • Sam Steingold
    Sam Steingold
    2009-05-08

    time.d patch which checks gmtime/localtime return values

     
  • Sam Steingold
    Sam Steingold
    2009-05-08

    please try the attached patch

     
  • Sam Steingold
    Sam Steingold
    2009-06-16

    thank you for your bug report.
    the bug has been fixed in the CVS tree.
    you can either wait for the next release (recommended)
    or check out the current CVS tree (see http://clisp.cons.org\)
    and build CLISP from the sources (be advised that between
    releases the CVS tree is very unstable and may not even build
    on your platform).

     
  • Sam Steingold
    Sam Steingold
    2009-06-16

    • assigned_to: haible --> sds
    • status: open --> closed-fixed