id summary reporter owner description type status priority milestone component version resolution keywords cc os architecture failure difficulty testcase blockedby blocking related 4970 time002 and time004 (ghci) test failures on OS X 64 bit gwright igloo "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, 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, 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. " bug closed high 7.2.1 GHCi 7.0.1 fixed AntoineLatter william.knop.nospam@… warrensomebody@… p.giarrusso@… MacOS X x86_64 (amd64) Incorrect result at runtime