This is the mail archive of the
mailing list for the Cygwin project.
Re: Seg Fault in strftime
- From: Jon TURNEY <jon dot turney at dronecode dot org dot uk>
- To: cygwin at cygwin dot com
- Cc: mike at kmcardiff dot com
- Date: Fri, 31 Jul 2015 13:51:37 +0100
- Subject: Re: Seg Fault in strftime
- Authentication-results: sourceware.org; auth=none
- References: <CAOC2fq9A1DSjy=7Af=wVCkNEsttpd4Fj-0w_nNwnSb76WFt5WA at mail dot gmail dot com>
- Reply-to: cygwin at cygwin dot com
On 31/07/2015 01:16, Michael Enright wrote:
The tznam is set from the tmzone member and when this happens that
member is garbage. This member is garbage POSSIBLY because of a
configuration option in libmozjs. The calling code is in prmjtime.cpp
fills in a struct tm from Spidermonkey's own broken-down time
structure, 'a', and then if the configuration enables, it makes
*another* struct tm with more fields filled in in order to get
a.tm_zone's proper value. My guess is that the path is not enabled but
the bits delivered to me do not disclose whether this righteous code
path is enabled. __cygwin_gettzname is evidently compiled to expect
the tm_zone member to exist because GDB shows it does exist.
Thanks for this investigation and analysis.
So did any aspect of this change recently? The application and library
were getting along okay before I did cygwin updates. The last time I
had tried to run this code was early June, at which time I was running
it dozens of times a day.
 looks like a highly relevant change and  is the associated discussion
It would be very helpful if you could tweak the testcase there and
produce one which reproduces your problem.
Also it appears that the tm_zone member is an extension. I haven't
been able to find POSIX guidance about how applications are supposed
use struct tm in compliance in the presence of implementation-defined
fields. POSIX example code shows a usage that does access the 'at
least' fields. The language allows for implementation-defined fields.
No mechanism is provided within POSIX to allow an application to
discover additional fields and take care of them. It seems to me that
an application can then assume that when it provides a struct tm as
input, filling in the time and date reasonably, it is always
sufficient to fill in the 'at least' fields and the implementation is
the one who has to assume that the rest of the fields might not be
Yeah, this seems a bit of an under-specified area.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple