Project

General

Profile

Actions

Bug #7276

closed

TestFile#test_utime failure

Added by jonforums (Jon Forums) about 12 years ago. Updated almost 12 years ago.

Status:
Closed
Target version:
ruby -v:
ruby 2.0.0dev (2012-11-04 trunk 37467) [i386-mingw32]
Backport:
[ruby-core:48854]

Description

I'm currently travelling and am in UTC-5. I get the following make test-all failure on Win7 32bit with mingw-w64 gcc 4.7.2. It appears that trunk@37467 is not handling daylight savings time correctly.

I'm not going to have time to try to repro on my Arch system, but can anyone else in UTC-5 (or other DST observing region) repro on either a Win7 or Linux system?

[ 3509/11467] TestFile#test_utime = 0.00 s
5) Failure:
test_utime(TestFile) [c:/Jenkins/workspace/ruby-trunk-svn/test/ruby/test_file.rb:287]:
[ruby-core:44776].
<2011-05-27 16:10:39 -0400> expected but was
<2011-05-27 15:10:39 -0400>.
...
Finished tests in 641.449135s, 17.8767 tests/s, 4150.9932 assertions/s.
11467 tests, 2662651 assertions, 1 failures, 0 errors, 83 skips

ruby -v: ruby 2.0.0dev (2012-11-04 trunk 37467) [i386-mingw32]


Related issues 1 (0 open1 closed)

Related to Backport193 - Backport #6385: mtime vie File.stat(filename).utime vs File.open(filename, 'r').mtime in WindowsClosedluislavena (Luis Lavena)05/01/2012Actions

Updated by jonforums (Jon Forums) about 12 years ago

Appears to be a trunk regression as TestFile#test_utime passes on ruby_1_9_3@37334

C:\Jenkins\workspace\ruby-1_9_3-svn>ruby -v test\ruby\test_file.rb
ruby 1.9.3p305 (2012-10-26 revision 37334) [i386-mingw32]
Run options:

Running tests:

................................

Finished tests in 1.154402s, 27.7200 tests/s, 127.3387 assertions/s.

Updated by mame (Yusuke Endoh) about 12 years ago

  • Status changed from Open to Assigned
  • Assignee set to nobu (Nobuyoshi Nakada)

Updated by jonforums (Jon Forums) about 12 years ago

Ping.

This is the only test-all fail I have when building trunk on Win7 with mingw-w64 gcc 4.7.2.

This fail does not show up at http://ci.rubyinstaller.org/ because the current build slaves reside in an area that doesn't participate in the daylight savings time circus.

Updated by luislavena (Luis Lavena) about 12 years ago

  • Assignee changed from nobu (Nobuyoshi Nakada) to usa (Usaku NAKAMURA)

Nakamura-san,

Do you have any idea about this? Nobu seems not responding so perhaps you can help us figure out the best solution for this.

Thank you.

Updated by jonforums (Jon Forums) about 12 years ago

No failure when building trunk@37710 on Arch 3.6.6 with gcc 4.7.2

Updated by h.shirosaki (Hiroshi Shirosaki) about 12 years ago

This seems due to r37337. I don't know the reason of r37337, but reverting the commit (use rb_w32_fstati64 for fstat) will fix this.

Updated by usa (Usaku NAKAMURA) about 12 years ago

  • Assignee changed from usa (Usaku NAKAMURA) to nobu (Nobuyoshi Nakada)

Updated by jonforums (Jon Forums) about 12 years ago

This still fails as of r38131 on my Win7 32bit system. Given Shirosaki-san's comment, what's preventing this from being quickly fixed on trunk?

Since this bug is not made visible by the rubyinstaller CI (build slave location) I will manually run any tests or builds you need in order to validate the fix. Let me know what you need.

Updated by jonforums (Jon Forums) almost 12 years ago

Status? Is this planned to be fixed for 2.0.0?

This is the only failure I get when building trunk (make test-all and make test) with mingw-w64 4.7.2 32bit on Win7.

As stated previously, you don't see this failure at http://ci.rubyinstaller.org/ because Luis' build slaves are located in an uneffected timezone.

Updated by phasis68 (Heesob Park) almost 12 years ago

This daylight savings time bug is described at
http://www.codeproject.com/Articles/1144/Beating-the-Daylight-Savings-Time-bug-and-getting
and
http://support.microsoft.com/kb/158588/en-us

The workaround is using the Windows API call instead of using the C library call.

Updated by jonforums (Jon Forums) almost 12 years ago

Nobu-san: why was r37337 required and rb_w32_fstati64 no longer correct?

Heesob: good read. After reverting r37337 as per Hiroshi's comment, I get 0 fails on trunk@38966 (Win7 32bit + mingw-w64 4.7.2) because fstat -> rb_w32_fstati64 (win32/win32.c:4474) rather than fstat -> _fstati64 which causes mingw-w64 to use msvcrt's _fstat64 (i686-w64-mingw32/include/_mingw_stat64.h:12)

http://msdn.microsoft.com/en-us/library/221w8e43%28v=vs.90%29.aspx

Given the info you linked, do you think the current rb_w32_fstati64 is a valid workaround? Does reverting r37337 also work for you on Win8?

Updated by phasis68 (Heesob Park) almost 12 years ago

Reverting r37337 works on Windows 8.

I think the only drawback to rb_w32_fstati64 is a little performance loss.

Updated by nobu (Nobuyoshi Nakada) almost 12 years ago

I don't remember the reason well, probably some mingw failed to link the dll or extension libraries.
But I can't find which failed, so revert it.

Actions #14

Updated by nobu (Nobuyoshi Nakada) almost 12 years ago

  • Status changed from Assigned to Closed
  • % Done changed from 0 to 100

This issue was solved with changeset r38992.
Jon, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.


win32.h: revert r37337

  • include/ruby/win32.h (fstat): revert r37337, which uses _fstati64()
    instead of fstati64() on mingw32. [Bug #7276]
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0