[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Findutils-patches] Re: [findutils-4.5.2] NULL pointer dereferencing, an

From: James Youngman
Subject: [Findutils-patches] Re: [findutils-4.5.2] NULL pointer dereferencing, and a trivial patch
Date: Sat, 13 Sep 2008 13:56:36 +0100

On Fri, Sep 12, 2008 at 9:07 PM, Nelson H. F. Beebe <address@hidden> wrote:
> Yesterday, I installed findutils-4.5.2 on about 25 flavors of Unix
> in our labs.  Today, we found that it gets a segment violation
> on Sun Solaris SPARC, easily replicated like this:

Thanks for your bug report!

>        find ~/.cshrc -printf '%TY'
> The backtrace of the core dump shows
> #0  0xff209678 in doformat () from /lib/
> #1  0xff209710 in strftime () from /lib/
> #2  0x0001734c in format_date (ts={tv_sec = 1221016463, tv_nsec = 381255880},
>    kind=89) at pred.c:2097

Thanks.   I suspect that this occurs because Solaris unconditionally
writes a terminating null character into the buffer, even if the
passed in size parameter is zero.

POSIX requires:

"If the total number of resulting bytes including the terminating null
byte is not more than maxsize, strftime() shall return the number of
bytes placed into the array pointed to by s, not including the
terminating null byte. Otherwise, 0 shall be returned and the contents
of the array are unspecified."


The code we have right now assumes that 0 will be correctly returned
if the buffer is too small.   However, it appears to me after some
digging around that Solaris may return a nonzero count even if the
buffer is too small.   So I would like you to try the attached patch
if you don't mind, to work around the problem.

> The installation tests did not catch this error: all of them passed.

Yes, the installation tests are particularly weak on time-related
tests and output.

> This may not logically be the desired thing (e.g., a 1KB size is
> arbitrary), but it allows the simple test to complete correctly, and
> prevents a NULL pointer being passed to strftime().

I believe I understand why this does work around the problem.   I'm
not set against using your patch.   However, please try the attached
patch instead.


Attachment: Attempted-Solaris-strftime-coredump-fix.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]