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
*********************
Thanks!!
|
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:
|
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:
so I thought this change would fix the problem. Do you have this changeset in your local git archive?
|
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.
|
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.
Problem still remains.
When the gnulib's mktime was updated?
|
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?
|
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)
|
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.
|
Wed 22 Dec 2010 03:05:52 AM UTC, comment #4:
Hello
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).
Thanks!!
Tatsuro
(file #22260)
|
Tue 21 Dec 2010 07:49:22 PM UTC, comment #3:
I recommend you try
and then keep stepping until you reach the point where it hangs.
|
Tue 21 Dec 2010 09:14:32 AM UTC, comment #2:
Hello
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.
However
*************************************************
octave.exe:2> datevec("03/13/1962")
(hanged without 'a=1')
*************************************************
????
Octave seemed to hang before function entry.
Regards
Tatsuro
|
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?
|
Sat 18 Dec 2010 12:01:39 PM UTC, original submission:
Hello
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 ?
Regards
Tatsuro
|