This is the mail archive of the
mailing list for the Cygwin project.
Re: Seg Fault in strftime
- From: Michael Enright <mike at kmcardiff dot com>
- To: cygwin at cygwin dot com
- Date: Fri, 31 Jul 2015 17:47:00 -0700
- Subject: Re: Seg Fault in strftime
- Authentication-results: sourceware.org; auth=none
- References: <CAOC2fq9A1DSjy=7Af=wVCkNEsttpd4Fj-0w_nNwnSb76WFt5WA at mail dot gmail dot com> <55BB6F59 dot 8060905 at dronecode dot org dot uk>
On Fri, Jul 31, 2015 at 5:51 AM, Jon TURNEY wrote:
> It would be very helpful if you could tweak the testcase there and produce
> one which reproduces your problem.
>  https://sourceware.org/ml/newlib/2015/msg00321.html
I took one more shot at reproduction and I think the problem is that
if code does a member-by-member initialization based on the fields
defined by POSIX, it is likely that tm_zone won't be initialized and
it could end up with a really bad value. Then strftime is likely to
You can improve the likelihood of a crash by filling a struct tm with
0x54, like I did, but random circumstances could also effectively
cause the same thing.
We could implore the local Cygwin maintainer of mozjs to make sure
that the code I mentioned earlier in that library zeros the struct tm,
but there is only defensive programming recommending that, not a
specification. And there could be other libraries or applications
already tripping over this but not yet spending time on investigating
If I took the time to think it through I think the additional logic
for handling a NULL tm_zone is not necessarily the cause of the
regression I'm facing, because the code I'm using through mozjs was
not setting that field to NULL in the first place.
I'm going to be away from the machines where I have this code at hand
for the next two weeks, reading email but not equipped to do anything
complicated about it.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple