32-bit testsuite failures

[daniel.is.fischer]

Running the testsuite on my old 32-bit box, I get a lot of failures I don't get on my 64-bit box.

resourceLimit: The compiled ways consistently fail with

Wrong exit code (expected 0 , actual 1 )
Stdout:

Stderr:
resourceLimit: setResourceLimit: invalid argument (Invalid argument)

ghci sometimes with the same message, sometimes with

Actual stdout output differs from expected:
--- ../../libraries/unix/tests/resourceLimit.stdout     2011-05-30 07:49:57.000000000 +0200
+++ ../../libraries/unix/tests/resourceLimit.run.stdout 2011-09-23 19:25:32.000000000 +0200
@@ -1,2 +1,2 @@
-5
-10
+18446744073709551615
+18446744073709551615

64 1-bits look as if some alignment broke.

ghcpkg01 and safePkg01: During the testsuite run, both fail with

Actual stderr output differs from expected:
...
+WARNING: cache is out of date: localXXX/package.cache
+  use 'ghc-pkg recache' to fix.

but when run on their own, both consistently pass. Since otherwise they behave as expected, it looks like a load-induced hiccough (which is a bit surprising because I ran the testsuite with THREADS=1, so there shouldn't be much going on to upset the tests).

Various recompilation-related failures: in tests/ghci, prog006, ghci.prog009, prog003, ghci027, 1914 all omit at least some recompilations and thus produce more or fewer error messages than expected resp. unexpected type info.

In tests/driver: recomp006 and T5147 fail with Wrong exit code (expected 0 , actual 2 ), both occasionally pass when run on their own; recomp001 doesn't produce the expected diagnostic, -C.hs:3:11: Module B' does not export foo', recomp009 produces the wrong stdout

Actual stdout output differs from expected:
--- ./driver/recomp009/recomp009.stdout	2011-07-29 10:44:03.000000000 +0200
+++ ./driver/recomp009/recomp009.run.stdout	2011-09-23 15:03:45.000000000 +0200
@@ -1,2 +1,2 @@
 1
-2
+1

and recomp005

@@ -3,6 +3,3 @@
 [3 of 5] Compiling C                ( C.hs, C.o )
 [4 of 5] Compiling D                ( D.hs, D.o )
 [5 of 5] Compiling E                ( E.hs, E.o )
-[3 of 5] Compiling C                ( C.hs, C.o )
-[4 of 5] Compiling D                ( D.hs, D.o )
-[5 of 5] Compiling E                ( E.hs, E.o )

In tests/ghc-api: apirecomp001 fails with

Wrong exit code (expected 0 , actual 2 )
Stdout:

Stderr:

myghc.hs:50:7: Not in scope: data constructor `RunFailed'
gmake[2]: *** [apirecomp001] Fehler 1

Last, the allocation figures for perf/compiler/T4801 haven't been adjusted for 32-bit systems, thus T4801 fails with

bytes allocated 231673896 is less than minimum allowed 330000000

I wouldn't like to set new limits myself without more data points.

[daniel.is.fischer]

Indeed, in System.Posix.Resource, things have changed. For my venerable 7.0.4, it was

getResourceLimit :: Resource -> IO ResourceLimits
getResourceLimit res = do
  allocaBytes (16) $ \p_rlimit -> do
{-# LINE 71 "libraries/unix/./System/Posix/Resource.hsc" #-}
    throwErrnoIfMinus1 "getResourceLimit" $
      c_getrlimit (packResource res) p_rlimit
    soft <- ((\hsc_ptr -> peekByteOff hsc_ptr 0)) p_rlimit
{-# LINE 74 "libraries/unix/./System/Posix/Resource.hsc" #-}
    hard <- ((\hsc_ptr -> peekByteOff hsc_ptr 8)) p_rlimit
{-# LINE 75 "libraries/unix/./System/Posix/Resource.hsc" #-}
    return (ResourceLimits { 
		softLimit = unpackRLimit soft,
		hardLimit = unpackRLimit hard
	   })

setResourceLimit :: Resource -> ResourceLimits -> IO ()
setResourceLimit res ResourceLimits{softLimit=soft,hardLimit=hard} = do
  allocaBytes (16) $ \p_rlimit -> do
{-# LINE 83 "libraries/unix/./System/Posix/Resource.hsc" #-}
    ((\hsc_ptr -> pokeByteOff hsc_ptr 0)) p_rlimit (packRLimit soft True)
{-# LINE 84 "libraries/unix/./System/Posix/Resource.hsc" #-}
    ((\hsc_ptr -> pokeByteOff hsc_ptr 8)) p_rlimit (packRLimit hard False)
{-# LINE 85 "libraries/unix/./System/Posix/Resource.hsc" #-}
    throwErrnoIfMinus1 "setResourceLimit" $
	c_setrlimit (packResource res) p_rlimit
    return ()

and HEAD's .hsc source got converted to

getResourceLimit :: Resource -> IO ResourceLimits
getResourceLimit res = do
  allocaBytes (8) $ \p_rlimit -> do
{-# LINE 74 "libraries/unix/./System/Posix/Resource.hsc" #-}
    throwErrnoIfMinus1 "getResourceLimit" $
      c_getrlimit (packResource res) p_rlimit
    soft <- ((\hsc_ptr -> peekByteOff hsc_ptr 0)) p_rlimit
{-# LINE 77 "libraries/unix/./System/Posix/Resource.hsc" #-}
    hard <- ((\hsc_ptr -> peekByteOff hsc_ptr 4)) p_rlimit
{-# LINE 78 "libraries/unix/./System/Posix/Resource.hsc" #-}
    return (ResourceLimits { 
                softLimit = unpackRLimit soft,
                hardLimit = unpackRLimit hard
           })

setResourceLimit :: Resource -> ResourceLimits -> IO ()
setResourceLimit res ResourceLimits{softLimit=soft,hardLimit=hard} = do
  allocaBytes (8) $ \p_rlimit -> do
{-# LINE 86 "libraries/unix/./System/Posix/Resource.hsc" #-}
    ((\hsc_ptr -> pokeByteOff hsc_ptr 0)) p_rlimit (packRLimit soft True)
{-# LINE 87 "libraries/unix/./System/Posix/Resource.hsc" #-}
    ((\hsc_ptr -> pokeByteOff hsc_ptr 4)) p_rlimit (packRLimit hard False)
{-# LINE 88 "libraries/unix/./System/Posix/Resource.hsc" #-}
    throwErrnoIfMinus1 "setResourceLimit" $
        c_setrlimit (packResource res) p_rlimit
    return ()

Which is very odd, because on the one hand, gcc confirms that sizeof(struct rlimit) is 8 (and sizeof(rlim_t) = 4), but on the other hand, resourceLimit passes with 7.0.4 which works with 16 resp. 8.

[daniel.is.fischer]

Ah, but HsBaseConfig.h says

#define HTYPE_RLIM_T Word64

in both source trees. I don't see how that ever worked with C expecting an 8-byte struct, but I see how writing two Word64s with an offset of four bytes would produce an invalid argument.

[simonmar]

This is a result of the breakage in #2897.