bugGNU Octave - Bugs: bug #31914, datevec("03/13/1962")...


bug #31914: datevec("03/13/1962") hangs on octave 3.3.54+ (MinGW)

Submitted by:  Tatsuro MATSUOKA <tmacchant>
Submitted on:  Sat 18 Dec 2010 12:01:39 PM UTC  
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  Tatsuro MATSUOKA Open/Closed:  Closed
Release:  dev Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Mon 31 Jan 2011 01:43:11 AM UTC, comment #12: 

Hello John and Benjamin

I have confirmed the problem is fixed after the gnulib mktime is updated.

octave.exe:1> datevec("03/13/1962")
ans =

   1962      3     13      0      0      0



Tatsuro MATSUOKA <tmacchant>
Sun 30 Jan 2011 08:29:47 AM UTC, comment #11: 

There is also this changeset that was checked in just a few moments ago:

commit ee9e39c014e2880179c91960ce1f69309d0c1500
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Sat Jan 29 23:59:31 2011 -0800

    TYPE_MAXIMUM: avoid theoretically undefined behavior

    * lib/intprops.h (TYPE_MINIMUM, TYPE_MAXIMUM): Do not shift a
    negative number, which the C Standard says has undefined behavior.
    In practice this is not a problem, but might as well do it by the book.
    Reported by Rich Felker and Eric Blake; see


John W. Eaton <jwe>
Project Administrator
Sun 30 Jan 2011 08:27:47 AM UTC, comment #10: 

It was fixed in the last 24 hours.  I see the following in the gnulib git archive:

commit 385b9f9d098b636827593dbd0f813c2b6858b308
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Sat Jan 29 15:47:04 2011 -0800

    mktime: fix some integer overflow issues and sidestep the rest

    This was prompted by a bug report by Benjamin Lindner for MinGW
    His bug is due to signed integer overflow (0 - INT_MIN), and I
    I scanned through mktime.c looking for other integer overflow
    problems, fixing all the bugs I found.


so I thought this change would fix the problem.  Do you have this changeset in your local git archive?

John W. Eaton <jwe>
Project Administrator
Sun 30 Jan 2011 08:27:21 AM UTC, comment #9: 

I went to gnulib site and see

mktime: #undef mktime before #defining it
author Paul Eggert <eggert@cs.ucla.edu>
Sun, 30 Jan 2011 07:04:27 +0000 (23:04 -0800)
committer Paul Eggert <eggert@cs.ucla.edu>
Sun, 30 Jan 2011 07:05:57 +0000 (23:05 -0800)
commit 56887e878833f53c8ca55371c0e4be66388e157b
tree 43f548bbabf566c303dfe305886b98a55464da5d tree | snapshot
parent 7b359a233b201ba4a65b3e9c947517046e011ea7 commit | diff

The commit for mktime is quite recently.  I will re pull and carry out the build.  Please wait for a while.

Tatsuro MATSUOKA <tmacchant>
Sun 30 Jan 2011 08:19:05 AM UTC, comment #8: 

I have built default branch.
Git pull and hg pull has carried out yesterday.

octave.exe:1> datevec("03/13/2000")
ans =

   2000      3     13      0      0      0

octave.exe:2> datevec("03/13/1971")
ans =

   1971      3     13      0      0      0

octave.exe:3> datevec("03/13/1970")
ans =

   1970      3     13      0      0      0

octave.exe:4> datevec("03/13/1969")

Problem still remains.

When the gnulib's mktime was updated?

Tatsuro MATSUOKA <tmacchant>
Sun 30 Jan 2011 07:55:42 AM UTC, comment #7: 

I think a fix for this problem may have been checked in to the gnulib sources.  Will you please update your copy of gnulib and check to see whether the problem is fixed in Octave?

John W. Eaton <jwe>
Project Administrator
Thu 27 Jan 2011 05:47:59 PM UTC, comment #6: 

Benjamin replied to the ML to the issue list I made.

I forwarded it here.

> confirmed, I tracked it as far as the call to
> strptime("03/13/1962","%m/%d/%Y") hang
> which more precicely hangs in the call to
>   gnulib::mktime (&t);
> in oct-time.cc, which in turn hangs on a call to ranged_convert() in
> libgnu/mktime.c.
> No further insight yet.

This is reproducable with gnulib's mktime standalone executable, so I
reported it to the gnulib bug list.
(all dates before 1970-01-01 01:00:00 show this behaviour)

Tatsuro MATSUOKA <tmacchant>
Wed 26 Jan 2011 05:41:13 AM UTC, comment #5: 

I don't see how that can be an infinite loop.  The loop that has line 126 is a for loop with a range from 1 to nfmt, which should be 21.  On my system, a match is found when the loop counter is 9.  So please keep stepping through this loop and continue until you find the real point where it hangs or loops indefinitely.

John W. Eaton <jwe>
Project Administrator
Wed 22 Dec 2010 03:05:52 AM UTC, comment #4: 


Thank you for your kind suggestion.

It's very convenient!!

I have attached a file of gdb trace.
The code seems to be in an infinite loop around
126:           if (found).



(file #22260)

Tatsuro MATSUOKA <tmacchant>
Tue 21 Dec 2010 07:49:22 PM UTC, comment #3: 

I recommend you try

octave:1> dbstop datevec
ans =  51
octave:2> datevec("03/13/1962")
stopped in /home/jwe/src/octave/scripts/time/datevec.m at line 51
51:   persistent std_formats nfmt;
debug> dbstep

and then keep stepping until you reach the point where it hangs.

John W. Eaton <jwe>
Project Administrator
Tue 21 Dec 2010 09:14:32 AM UTC, comment #2: 


I have tried
./run-octave -g

(gdb) run
octave.exe:1> datevec("03/13/1962")
(octave return no response)

I pressed Ctrl+C

The gdb process was terminated and I saw the shell prompt '$'.
octave.exe:1> datevec("03/13/1962")
[New Thread 3068.0x27cc]

$ <- shell prompt

Therefore I have abandon gdb trace and tried to insert a=1 to datevec.m as

function [y, m, d, h, mi, s] = datevec (date, varargin)
a=1 # <- here
  persistent std_formats nfmt;

And then I have tried the following from the octave prompt

octave.exe:1> datevec("07-Sep-2000 15:38:09")
a =  1
ans =

   2000      9      7     15     38      9
'a=1' appear as expected.

octave.exe:2> datevec("03/13/1962")
(hanged without 'a=1')
Octave seemed to hang before function entry.



Tatsuro MATSUOKA <tmacchant>
Tue 21 Dec 2010 04:33:20 AM UTC, comment #1: 

Can you please run Octave under gdb and find out where it is hangning?

John W. Eaton <jwe>
Project Administrator
Sat 18 Dec 2010 12:01:39 PM UTC, original submission:  


I have built development source on MinGW.

changeset information
author John W. Eaton <jwe@octave.org>
Fri Dec 17 15:21:33 2010 -0500 (3 hours ago)
changeset 11382 ed74d1fbdc2f
parent 11381 d27008c32e0d

During the fntests, octave have been in no respose state in the datevec.m test.

I have executed manually what was wrong.
I found out the datevec("03/13/1962") hangs.

All other tests for datevec have been finished correctly.

BTW, on octave 3.2.4 on MinGW

octave:2> datevec("03/13/1962")
ans =

   1962      3     13      0      0      0
Worked correctly.

Any suggestions ?



Tatsuro MATSUOKA <tmacchant>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #22260:  datevec_03_13_1962.txt added by tmacchant (14KiB - text/plain)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by tmacchant
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by tmacchant (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-01-31 jwe StatusNone => Fixed
        Open/ClosedOpen => Closed
    2011-01-27 tmacchant Carbon-Copy- => Added "benjamin lindner" <bjmldn@gmail.com>
    2010-12-22 tmacchant Attached File- => Added datevec_03_13_1962.txt, #22260

    Back to the top

    Powered by Savane 3.5