asctime(0) Segmentation fault

asctime(0) Segmentation fault

[John Mudd]

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

I found this by running "make test" on musl build of Python.

$ cat test_asctime.c
#include <time.h>
#include <stdio.h>

int main()
{
    char *c = asctime(0);
    printf("After asctime\n");
    if (c) printf("c=%s", c);
}
$ gcc test_asctime.c   -o test_asctime
$ test_asctime
After asctime
$ musl-gcc test_asctime.c   -o test_asctime
$ test_asctime
Segmentation fault (core dumped)
$

[-- Attachment #2: Type: text/html, Size: 672 bytes --]

Re: asctime(0) Segmentation fault

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

Just curious, would should asctime(0) do instead?

Jens

-- 
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/   ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090   ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536   ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183   ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: asctime(0) Segmentation fault

[John Mudd]

[-- Attachment #1: Type: text/plain, Size: 255 bytes --]

It looks like asctime(0) should return 0 instead of Segmentation fault.


On Sat, Apr 19, 2014 at 6:16 PM, John Mudd <johnbmudd@gmail.com> wrote:

>
> $ musl-gcc test_asctime.c   -o test_asctime
> $ test_asctime
> Segmentation fault (core dumped)
> $
>
>

[-- Attachment #2: Type: text/html, Size: 640 bytes --]

Re: Re: asctime(0) Segmentation fault

[Szabolcs Nagy]

* John Mudd <johnbmudd@gmail.com> [2014-04-19 18:46:42 -0400]:
> It looks like asctime(0) should return 0 instead of Segmentation fault.

no

what was the python test failure?

my guess is that they pass something to asctime without checking for 0

that something being 0 may be a musl bug or a python test framework bug

Re: Re: asctime(0) Segmentation fault

[Rich Felker]

On Sun, Apr 20, 2014 at 03:43:39AM +0200, Szabolcs Nagy wrote:
> * John Mudd <johnbmudd@gmail.com> [2014-04-19 18:46:42 -0400]:
> > It looks like asctime(0) should return 0 instead of Segmentation fault.
> 
> no

To elaborate, 0 is not a valid pointer to struct tm, so the behavior
is undefined. The preferred response to undefined behavior is always
an immediate crash. In some cases that's not possible, or at least
would involve significant additional effort to achieve. But here, like
many places, it's the automatic natural behavior.

It's definitely not acceptable to bury undefined behavior that would
otherwise be caught by special-casing it with code to ignore it. The
proposed behavior (returning a null string pointer) would propagate
the error further and it would be more work to determine the origin of
the error (or it might not be detected at all).

> what was the python test failure?
> 
> my guess is that they pass something to asctime without checking for 0
> 
> that something being 0 may be a musl bug or a python test framework bug

Indeed, this would be interesting to know, as it might reveal a real
bug (either a bug in musl we need to fix, or a portability bug in
python that's affecting its use on musl).

Rich

Re: asctime(0) Segmentation fault

[John Mudd]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

From Python-2.7.6/Lib/test/test_time.py:

    def test_asctime(self):
        time.asctime(time.gmtime(self.t))
        self.assertRaises(TypeError, time.asctime, 0)



On Sat, Apr 19, 2014 at 6:46 PM, John Mudd <johnbmudd@gmail.com> wrote:

> It looks like asctime(0) should return 0 instead of Segmentation fault.
>
>

[-- Attachment #2: Type: text/html, Size: 767 bytes --]

Re: asctime(0) Segmentation fault

[John Mudd]

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

That was incomplete.

From Python-2.7.6/Lib/test/test_time.py:

    def test_asctime(self):
        time.asctime(time.gmtime(self.t))
        self.assertRaises(TypeError, time.asctime, 0)
        self.assertRaises(TypeError, time.asctime, ())
        # XXX: Posix compiant asctime should refuse to convert
        # year > 9999, but Linux implementation does not.
        # self.assertRaises(ValueError, time.asctime,
        #                  (12345, 1, 0, 0, 0, 0, 0, 0, 0))
        # XXX: For now, just make sure we don't have a crash:
        try:
            time.asctime((12345, 1, 1, 0, 0, 0, 0, 1, 0))
        except ValueError:
            pass



>>> import time
>>> time.asctime((12345, 1, 1, 0, 0, 0, 0, 1, 0))
'Mon Jan  1 00:00:00 12345\n'
>>>

musl:
>>> import time
>>> time.asctime((12345, 1, 1, 0, 0, 0, 0, 1, 0))
Segmentation fault (core dumped)




On Sat, Apr 19, 2014 at 10:43 PM, John Mudd <johnbmudd@gmail.com> wrote:

> From Python-2.7.6/Lib/test/test_time.py:
>
>
>

[-- Attachment #2: Type: text/html, Size: 1795 bytes --]

Re: Re: asctime(0) Segmentation fault

[Rich Felker]

On Sat, Apr 19, 2014 at 10:51:34PM -0400, John Mudd wrote:
> That was incomplete.
> 
> >From Python-2.7.6/Lib/test/test_time.py:
> 
>     def test_asctime(self):
>         time.asctime(time.gmtime(self.t))
>         self.assertRaises(TypeError, time.asctime, 0)
>         self.assertRaises(TypeError, time.asctime, ())
>         # XXX: Posix compiant asctime should refuse to convert
>         # year > 9999, but Linux implementation does not.

This is false. POSIX explicitly says the behavior is undefined:

    However, the behavior is undefined if timeptr->tm_wday or
    timeptr->tm_mon are not within the normal ranges as defined in
    <time.h>, or if timeptr->tm_year exceeds {INT_MAX}-1990, or if the
    above algorithm would attempt to generate more than 26 bytes of
    output (including the terminating null).

(http://pubs.opengroup.org/onlinepubs/9699919799/functions/asctime.html)

This agrees with ISO C.

Thus the test Python is performing is invalid.

However I'm unclear on how it involves a null pointer being passed to
asctime. Are you sure this is actually the offending test?

Rich

Re: asctime(0) Segmentation fault

[John Mudd]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

Yes, asctime(0) might be my bad assumption.

Does this help?

(gdb) backtrace
#0  a_crash () at ./arch/i386/atomic.h:124
#1  0xb7fc735b in __asctime (tm=0xbfffde64, buf=0xb7fff288 <buf.1032> "Mon
Jan  1 00:00:00 12345") at src/time/__asctime.c:26
#2  0xb7fc91d7 in asctime (tm=tm@entry=0xbfffde64) at src/time/asctime.c:8
#3  0xb7c89709 in time_asctime (self=0x0, args=0xb7d05bcc) at
/home/mudd/musl/Python-2.7.6/Modules/timemodule.c:574
#4  0xb7e1989d in PyCFunction_Call (func=func@entry=0xb7d056cc,
arg=arg@entry=0xb7d05bcc, kw=kw@entry=0x0) at Objects/methodobject.c:81




On Sat, Apr 19, 2014 at 10:51 PM, John Mudd <johnbmudd@gmail.com> wrote:

>
> musl:
> >>> import time
> >>> time.asctime((12345, 1, 1, 0, 0, 0, 0, 1, 0))
> Segmentation fault (core dumped)
>
>
>

[-- Attachment #2: Type: text/html, Size: 1367 bytes --]

Re: Re: asctime(0) Segmentation fault

[Rich Felker]

On Sat, Apr 19, 2014 at 11:33:06PM -0400, John Mudd wrote:
> Yes, asctime(0) might be my bad assumption.
> 
> Does this help?
> 
> (gdb) backtrace
> #0  a_crash () at ./arch/i386/atomic.h:124
> #1  0xb7fc735b in __asctime (tm=0xbfffde64, buf=0xb7fff288 <buf.1032> "Mon
> Jan  1 00:00:00 12345") at src/time/__asctime.c:26
> #2  0xb7fc91d7 in asctime (tm=tm@entry=0xbfffde64) at src/time/asctime.c:8
> #3  0xb7c89709 in time_asctime (self=0x0, args=0xb7d05bcc) at
> /home/mudd/musl/Python-2.7.6/Modules/timemodule.c:574
> #4  0xb7e1989d in PyCFunction_Call (func=func@entry=0xb7d056cc,
> arg=arg@entry=0xb7d05bcc, kw=kw@entry=0x0) at Objects/methodobject.c:81

Yes. musl's asctime is intentionally crashing when the resulting
string would be >26 bytes rather than silently clobbering whatever
memory lies just beyond the end of the static buffer.

Rich