X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:date:message-id:subject:from:to
	:content-type; q=dns; s=default; b=DwGH07x6coCibjjrhY9Wnm6PAaI6l
	SAC+ZBcewJyBNJ005NkLZLtyz5yMzO0hTebtsvsUA6wjd5ATaJGluLMFn2e9HyDE
	pSD2eqj/7KiNnCZFnyEcX1W9XvoLbvmU/mfVUDO2x2j4lXlyoLjCM3L51N+V2kux
	xxhg9sYOsk6Fgk=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:date:message-id:subject:from:to
	:content-type; s=default; bh=B01NGZVa8ZnZC9WE0r/W7+ZTMgQ=; b=CGW
	lRAbGKETQoKLsOqL94f4ix1FLtQcqlBT0P9PmCqtkMltoyjQlXtnc5vhMqbAZbvC
	OiC0v/Vz4JLHxOHGf+wckuWtfGnviTDg4C+egQY9aFi4b1uvW2prkNbbpIJd4j39
	dzj5EksWyIu8haNIhnuq2BjBpWck7APxM4VVSmpY=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO:	mail-lb0-f193.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=+ooLHntjVtyphDiY09HthpC/xRUcolE3Ucsoeq2An7A=; b=gHSDNbgPViwQ+qVzo8MYRT3cP0dpbGsomfCf9UbTefcx8Hw0JmVzXltE48IqT1LeSZ /iOb/Zn3L+SV6WHFfanc4XDJR4wBIh5+f8sk6S+rjSh3XrXTVVKm63H46tFefD0RAO/r guCoHdRvZBgnbBP9Z1IvvVMAaMz4fWmxi9nWvbfkt/IaUHcnhETm0yoS9mZAM1b8/F5l sMgUMtegKQwHkZhE0Zzd6iJKWnYy4niu5iH3XRFZJrEOLgZvFsZIZXQ2ojkXPayF8qiO HE4nGwhE7IiyeddBiaTOeUgsH7MrYVFzR4kcZKRz/Gvv1gHyAUxSeFpdBLM5braeiU6F goNA==
X-Gm-Message-State:	ALoCoQkP+NDb3Jiaq+Kc6Gqtc7UGy7ywGhPVMXZL0wxeiGc0Ea+lUtTGa0pbzDYdysbDCC/IwIH9
MIME-Version:	1.0
X-Received:	by 10.152.23.4 with SMTP id i4mr46836844laf.51.1438301788115; Thu, 30 Jul 2015 17:16:28 -0700 (PDT)
Date:	Thu, 30 Jul 2015 17:16:28 -0700
Message-ID:	<CAOC2fq9A1DSjy=7Af=wVCkNEsttpd4Fj-0w_nNwnSb76WFt5WA@mail.gmail.com>
Subject:	Seg Fault in strftime
From:	Michael Enright <mike AT kmcardiff DOT com>
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes

In a thread about navigating a stackdump to find out what's going
wrong, I posted the output of a GDB session as follows.

On Thu, Jul 30, 2015 at 11:48 AM, Michael Enright  wrote:
>
> (gdb) print tznam
> $3 = 0xc07a4000 <error: Cannot access memory at address 0xc07a4000>
> (gdb) list
> 1339                    tznam = _tzname[tim_p->tm_isdst > 0];
> 1340                  /* Note that in case of wcsftime this loop only works for
> 1341                     timezone abbreviations using the portable
> codeset (aka ASCII).
> 1342                     This seems to be the case, but if that ever
> changes, this
> 1343                     loop needs revisiting. */
> 1344                  size = strlen (tznam);
> 1345                  for (i = 0; i < size; i++)
> 1346                    {
> 1347                      if (count < maxsize - 1)
> 1348                        s[count++] = tznam[i];
> (gdb) print _tzname
> $4 = {0x800cfc48 "\200", <incomplete sequence \356\066>, 0x800cfc44 "PDT"}
> (gdb) print _tzname[0]
> $5 = 0x800cfc48 "\200", <incomplete sequence \356\066>
> (gdb) print _tzname[1]
> $6 = 0x800cfc44 "PDT"
>

This is a little misleading. The code at or near line 1339 looks like this:
1331 #if defined (__CYGWIN__)
1332     /* See above. */
1333      extern const char *__cygwin_gettzname (const struct tm *tmp);
1334      tznam = __cygwin_gettzname (tim_p);
1335 #elif defined (__TM_ZONE)
1336      tznam = tim_p->__TM_ZONE;
1337 #endif
1338      if (!tznam)
1339        tznam = _tzname[tim_p->tm_isdst > 0];

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.

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.

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
filled in.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -