time002 and time004 (ghci) test failures on OS X 64 bit
The time002
and time004
tests fail for ghci
on OS X 64 bit. The failure doesn't happen every time, but when it does, the failure is the same:
plumbbob-franklin> inplace/bin/ghc-stage2 --interactive time002.hs
GHCi, version 7.0.1.20101221: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
[1 of 1] Compiling Main ( time002.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Loading package array-0.3.0.2 ... linking ... done.
Loading package filepath-1.2.0.0 ... linking ... done.
Loading package old-locale-1.0.0.2 ... linking ... done.
Loading package old-time-1.0.0.6 ... linking ... done.
Loading package unix-2.4.1.0 ... linking ... done.
Loading package directory-1.1.0.0 ... linking ... done.
Loading package process-1.0.1.5 ... linking ... done.
Loading package time-1.2.0.3 ... linking ... done.
Loading package random-1.0.0.3 ... linking ... done.
Loading package haskell98-1.1.0.1 ... linking ... done.
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
*** Exception: Time.toClockTime: picoseconds out of range
*Main> main
Ok.
*Main>
If I modify the test to print the results of getClockTime
and toCalendarTime
, I see
plumbbob-franklin> inplace/bin/ghc-stage2 --interactive time002.hs
GHCi, version 7.0.1.20101221: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
[1 of 1] Compiling Main ( time002.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Loading package array-0.3.0.2 ... linking ... done.
Loading package filepath-1.2.0.0 ... linking ... done.
Loading package old-locale-1.0.0.2 ... linking ... done.
Loading package old-time-1.0.0.6 ... linking ... done.
Loading package unix-2.4.1.0 ... linking ... done.
Loading package directory-1.1.0.0 ... linking ... done.
Loading package process-1.0.1.5 ... linking ... done.
Loading package time-1.2.0.3 ... linking ... done.
Loading package random-1.0.0.3 ... linking ... done.
Loading package haskell98-1.1.0.1 ... linking ... done.
Sat Feb 19 10:12:35 EST 2011
CalendarTime {ctYear = 2011, ctMonth = February, ctDay = 19, ctHour = 10, ctMin = 12, ctSec = 35, ctPicosec = 112417000000, ctWDay = Saturday, ctYDay = 49, ctTZName = "EST", ctTZ = -18000, ctIsDST = False}
Ok.
*Main> main
Sat Feb 19 10:12:37 EST 2011
CalendarTime {ctYear = 2011, ctMonth = February, ctDay = 19, ctHour = 10, ctMin = 12, ctSec = 37, ctPicosec = 4295408225000000, ctWDay = Saturday, ctYDay = 49, ctTZName = "EST", ctTZ = -18000, ctIsDST = False}
*** Exception: Time.toClockTime: picoseconds out of range
*Main>
The ctPicosec
field is too big.
The interesting thing is that if I dump the relocations for HSold-time-1.0.0.6.o, and grep for ctPicosec
, I see
plumbbob-franklin> otool -rv HSold-time-1.0.0.6.o | grep ctPicosec
00023c5d False long True SUB False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_info_dsp
00023c5d False long True UNSIGND False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_info
00023c55 True long True SIGNED False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_closure
00001cf8 False quad True UNSIGND False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_info
The first relocation is an X86_64_RELOC_SUBTRACTOR
. This is probably being done incorrectly. (It may be distantly related to #4013 (closed), which also seems to be a subtractor relocation gone awry, but in that case of x86. The details of the x86 and x86_64 cases are quite different, but the original code for both cases is from the same author.)
After the patch that fixed #4867 (closed), there between five and seven test failures that only involve ghci
. I'm uncertain about two because I've been building unthreaded to simplify debugging and two tests require threads. I suspect linker bugs in all these cases.
I've found a convenient list of x86_64 relocation examples at http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachOTopics/1-Articles/dynamic_code.html#//apple_ref/doc/uid/TP40002528-SW1. I'll check the OS X 64 bit linker in its current state against these. Unfortunately, the list does not seem to be exhaustive. For instance, it doesn't contain the inter-section relocation that was at issue in #4867 (closed).
Trac metadata
Trac field | Value |
---|---|
Version | 7.0.1 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | GHCi |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |