#4970: time002 and time004 (ghci) test failures on OS X 64 bit
-------------------------------+--------------------------------------------
Reporter: gwright | Owner:
Type: bug | Status: new
Priority: normal | Component: GHCi
Version: 7.0.1 | Keywords:
Testcase: | Blockedby:
Os: MacOS X | Blocking:
Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime
-------------------------------+--------------------------------------------
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.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4970>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
