Opened 9 years ago

Closed 9 years ago

#4247 closed bug (duplicate)

getCPUTime on x86_64 Mac OS X 10.6

Reported by: quark Owned by: igloo
Priority: high Milestone: 7.2.1
Component: libraries/base Version: 6.10.4
Keywords: Cc: johan.tibell@…, william.knop.nospam@…
Operating System: MacOS X Architecture: x86_64 (amd64)
Type of failure: Incorrect result at runtime Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


I have GHC 6.10.4 installed on a recent Mac Mini, which is running a 32-bit kernel (Snow Leopard, 10.6) but has 64-bit GHC installed, using MacPorts. I've compiled a very large commercial product with this installation (with FFI etc) and the product's testsuite passes, so I'm fairly confident that GHC is working ... except that "getCPUTime" is giving bogus values.

This simple program:

import CPUTime
fn = do t <- getCPUTime
        putStrLn ("t = " ++ show t)
main :: IO ()
main = fn

ought to produce increasing values of "t". However, the output jumps around wildly, from 1022, to 1024, to 1015.

Change History (11)

comment:1 Changed 9 years ago by igloo

Milestone: 6.14.2
Owner: set to igloo

How are you compiling it?

comment:2 Changed 9 years ago by quark

For the simple example, I'm just running "ghc Main.hs" and then running the generated "a.out" binary. Is there more information can I give you that would be helpful?

comment:3 Changed 9 years ago by igloo

No, thanks, that's great. I'll take a look once we have an OS X 64 build for 6.14.1.

comment:4 Changed 9 years ago by Atze

The problem can be traced to OSX 64 bits using two different sized types for the rusage.ru_utime.tv_sec and rusage.ru_utime.tv_usec fields, the first a time_t, the second a useconds_t. On most platforms these are equally sized, and equal to time_t. However, when different (in this case 64 bits and 32 bits resp.) the code in CPUTime.hs incorrectly assumes that both fields are of type CTime. The solution is probably to introduce a new type for useconds_t, like CUSeconds, check for its size at configuration time, and adapt CPUTime.hs to take this into account.

I ran into this problem with UHC as well.

comment:5 Changed 9 years ago by igloo

Aha, thanks for the info, Atze!

comment:6 Changed 9 years ago by igloo

This may be caused by #4852.

comment:7 Changed 9 years ago by igloo


comment:8 Changed 9 years ago by gwright

This is essentially the same bug as #4970, so it looks like more than one file needs to be fixed.

comment:9 Changed 9 years ago by simonmar

Priority: normalhigh

Bumping prio to match #4970, which is the same bug in a different module.

comment:10 Changed 9 years ago by tibbe

Cc: johan.tibell@… added

comment:11 Changed 9 years ago by altaic

Cc: william.knop.nospam@… added
Resolution: duplicate
Status: newclosed

Marking this as a dup of #4970. The patch for this ticket requires a patch common to #4970 (adding the Haskell type for suseconds_t), so you'll find all the patches there.

Note: See TracTickets for help on using tickets.