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