GNU bug report logs - #30738
Invalid timezone (tzalloc failure) treated as out-of-memory

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30738 in the body.
You can then email your comments to 30738 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Valery Ushakov <uwe <at> stderr.spb.ru>
To: bug-gnu-emacs <at> gnu.org
Subject: Invalid timezone (tzalloc failure) treated as out-of-memory
Date: Wed, 7 Mar 2018 01:53:46 +0300

Emacs 25 treats tzalloc(3) failure as out-of-memory condition.
E.g. when an invalid timezone is specified, it fails to start with:

$ TZ=FOOBAR emacs -nw
emacs: Memory exhausted--use M-x save-some-buffers then exit and restart Emacs


The code in tzlookup() also assumes that tzalloc(3) understands the
direct zone specification in the name/offset format.  I haven't
checked tzcode history, but this support is only a few years old
(around 2014, I'd estimate).  E.g. NetBSD-6 has older tzcode(3) that
doesn't support this feature.  This leads to a lot of "Memory
exhausted" errors when trying to use e.g. vc.el

  "encode-time" (0xffffa2d4)
  "apply" (0xffffa3fc)
  "vc-cvs-parse-entry" (0xffffa718)
  "vc-cvs-registered" (0xffffa9b0)
  "progn" (0xffffab44)
  "if" (0xffffac24)
  "vc-cvs-registered" (0xffffae7c)
  "apply" (0xffffae78)
  "vc-call-backend" (0xffffb188)
  0x1c65360 PVEC_COMPILED
  "mapc" (0xffffb5c8)
  "vc-registered" (0xffffb8d8)
  "vc-backend" (0xffffbbe8)
  "vc-refresh-state" (0xffffbfa0)
  "run-hooks" (0xffffc08c)
  "after-find-file" (0xffffc3b4)
  ...

-uwe

Message #10 received at 30738-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Valery Ushakov <uwe <at> stderr.spb.ru>
Cc: 30738-done <at> debbugs.gnu.org
Subject: Re: Invalid timezone (tzalloc failure) treated as out-of-memory
Date: Sun, 11 Mar 2018 00:33:03 -0800

[Message part 1 (text/plain, inline)]

[resending, I hope to the right place this time]

Thanks for reporting the problem. I have installed the attached two patches,
which I think should fix the problem so I'm closing the bug report. Please give
them a try on NetBSD (as I typically don't use NetBSD).

[0001-Fix-minor-timezone-memory-leak.patch (text/x-patch, attachment)]

[0001-Port-to-NetBSD-tzalloc.patch (text/x-patch, attachment)]

Message #13 received at 30738-done <at> debbugs.gnu.org (full text, mbox):

From: Valery Ushakov <uwe <at> stderr.spb.ru>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 30738-done <at> debbugs.gnu.org
Subject: Re: Invalid timezone (tzalloc failure) treated as out-of-memory
Date: Mon, 12 Mar 2018 22:10:02 +0300

On Sun, Mar 11, 2018 at 00:33:03 -0800, Paul Eggert wrote:

> Thanks for reporting the problem.  I have installed the attached two
> patches, which I think should fix the problem so I'm closing the bug
> report.  Please give them a try on NetBSD (as I typically don't use
> NetBSD).

Thank you for your prompt response.  This helps but only partially.

Now emacs doesn't freak out with a scary message when tzalloc()
returns NULL, but tzlookup() still calls tzalloc("XXXhh:mm:ss") for
integer "zone".  Unfortunately, as I mentioned in the original
submission, tzcode in NetBSD-6 doesn't grok that (support for that
appeared in tzcode only around 2014 I think), so each time you open a
file under CVS control you get the "Invalid time zone" error.

Perhaps in the long term configure should try to detect if host's
tzalloc() understands that kind of direct timezone specification.

However in the case of CVS the offending zone value is zero that comes
from parsed-time-string, so the following quick hack can be used

--- editfns.c.dist	2017-04-14 18:02:47.000000000 +0300
+++ editfns.c	2018-03-12 21:46:58.000000000 +0300
@@ -153,7 +147,8 @@
 
   if (NILP (zone))
     return local_tz;
-  else if (EQ (zone, Qt))
+  else if (EQ (zone, Qt)
+	   || (INTEGERP (zone) && XINT (zone) == 0))
     {
       zone_string = "UTC0";
       new_tz = utc_tz;

I don't know if CVS always uses UTC or it's just because the CVS repos
I work with all use UTC as an adminsitrative decision.  Though I guess
it can be argued that special-casing zone 0 like that to return utc_tz
is the right thing to do regardless.

Thanks.

-uwe

Message #16 received at 30738 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Valery Ushakov <uwe <at> stderr.spb.ru>
Cc: 30738 <at> debbugs.gnu.org
Subject: Re: Invalid timezone (tzalloc failure) treated as out-of-memory
Date: Thu, 15 Mar 2018 09:43:20 -0700

[Message part 1 (text/plain, inline)]

On 03/12/2018 12:10 PM, Valery Ushakov wrote:
> -  else if (EQ (zone, Qt))
> +  else if (EQ (zone, Qt)
> +	   || (INTEGERP (zone) && XINT (zone) == 0))

Thanks for diagnosing the problem. If I understand things correctly, we 
can do a more-general fix, which should work for any used-in-practice 
time zone that is an integer hour offset from UTC. I installed the 
attached patch into master; please give it a try. I don't have easy 
access to NetBSD and would appreciate your testing it on NetBSD 6 and 7. 
I think this problem is limited to older NetBSD and so is not worth 
testing for in configure.ac (as 'configure' is pretty slow already).

[0001-Improve-port-to-NetBSD-tzalloc.txt (text/plain, attachment)]

Message #19 received at 30738 <at> debbugs.gnu.org (full text, mbox):

From: Valery Ushakov <uwe <at> stderr.spb.ru>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 30738 <at> debbugs.gnu.org
Subject: Re: Invalid timezone (tzalloc failure) treated as out-of-memory
Date: Mon, 19 Mar 2018 19:29:43 +0300

On Thu, Mar 15, 2018 at 09:43:20 -0700, Paul Eggert wrote:

> On 03/12/2018 12:10 PM, Valery Ushakov wrote:
> > -  else if (EQ (zone, Qt))
> > +  else if (EQ (zone, Qt)
> > +	   || (INTEGERP (zone) && XINT (zone) == 0))
> 
> Thanks for diagnosing the problem. If I understand things correctly, we can
> do a more-general fix, which should work for any used-in-practice time zone
> that is an integer hour offset from UTC. I installed the attached patch into
> master; please give it a try.

Sorry, I still haven't got around to test it, but I used exactly the
same approach with Etc/GMT* zones as a kludge when I first ran into
this problem and needed a working emacs asap.  I'll try to actually
test your patch this week.

I'd say special casing 0 is still a good idea as it saves a call to
tzalloc().  I also suspect that zone == 0 from parsed-time-string is
the most common case.

-uwe

Message #22 received at 30738 <at> debbugs.gnu.org (full text, mbox):

From: Valery Ushakov <uwe <at> stderr.spb.ru>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 30738 <at> debbugs.gnu.org
Subject: Re: Invalid timezone (tzalloc failure) treated as out-of-memory
Date: Mon, 19 Mar 2018 23:24:25 +0300

On Thu, Mar 15, 2018 at 09:43:20 -0700, Paul Eggert wrote:

> On 03/12/2018 12:10 PM, Valery Ushakov wrote:
> > -  else if (EQ (zone, Qt))
> > +  else if (EQ (zone, Qt)
> > +	   || (INTEGERP (zone) && XINT (zone) == 0))
> 
> Thanks for diagnosing the problem. If I understand things correctly, we can
> do a more-general fix, which should work for any used-in-practice time zone
> that is an integer hour offset from UTC. I installed the attached patch into
> master; please give it a try. I don't have easy access to NetBSD and would
> appreciate your testing it on NetBSD 6 and 7.

I've tested it and this patch also needs to #include <sys/param.h>
where __NetBSD_Version__ is defined.

PS: As an aside, that %+ made me realize that tzbuf_format can
probably drop that artisanal &"-"[...] and its corresponding %s, and
just pass -hour instead.

-uwe

Message #25 received at 30738 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Valery Ushakov <uwe <at> stderr.spb.ru>
Cc: 30738 <at> debbugs.gnu.org
Subject: Re: Invalid timezone (tzalloc failure) treated as out-of-memory
Date: Mon, 19 Mar 2018 16:55:25 -0700

[Message part 1 (text/plain, inline)]

On 03/19/2018 09:29 AM, Valery Ushakov wrote:
> special casing 0 is still a good idea as it saves a call to
> tzalloc().

Fair enough; I installed the first attached patch.


> this patch also needs to #include <sys/param.h>
> where __NetBSD_Version__ is defined.

Thanks, I installed the second attached patch to do that.


> tzbuf_format can
> probably drop that artisanal &"-"[...] and its corresponding %s, and
> just pass -hour instead.

That would mishandle time zones like -00:30:00 (i.e., 30 minutes behind 
UTC). That is, the sign is a property of the minutes and the seconds 
too, not just the hours.

[0001-Tune-time-zone-0.patch (text/x-patch, attachment)]

[0001-Improve-port-to-NetBSD-tzalloc.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.