[patch] bug #6524 - ctime() on bad values hangs system

[Mark Wielaard]

Hi,

On Sat, 2008-05-17 at 04:20 +0200, Mark Wielaard wrote:
> While playing a bit with ctime I hit bug #6524. Since ctime() accepts a
> 64bit long the year/month/day computation could take ages when given a
> bogus epoch offset. The following patch makes it so that the printed
> string is capped to somewhat reasonable values, otherwise it just
> returns "a long, long time ago...", or "far far in the future...". Care
> is taken to make sure that the returned string is always 24 chars wide.
> Also included is a new ctime test against some corner case values.

After testing on a 32bit system and after comments from Frank I changed
two things. I cap the value now to what would fit in a time_t on 32bit
systems (the calculations were already using native long values). And I
shouldn't have changed the MAX_STRINGLENGTH in lcpy and snprintf to 25,
that was too smart. The user should be able to override this.

Pushed as follows:

tapset/ChangeLog
2008-05-19  Mark Wielaard  <mwielaard@redhat.com>

    PR6524
    * ctime.stp: Don't try to convert values that won't fit in 32bits.

testsuite/ChangeLog
2008-05-19  Mark Wielaard  <mwielaard@redhat.com>

    PR 6524
    * systemtap.base/ctime.stp: New test.
    * systemtap.base/ctime.exp: New expect file.

Cheers,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ctime.patch
Type: text/x-patch
Size: 4434 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20080520/e6d329b1/attachment.bin>