#8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. -------------------------------------+----------------------------- Reporter: k0da | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by yama): This bug seems to apear on Debian ppc64 port, too. If we believe the build logs of Debian's autobuild system for ppc64, building of ghc 7.6.1, 7.6.2, and 7.6.3 with ghc 7.4.1 succeeded. http://buildd.debian-ports.org/status/logs.php?pkg=ghc&arch=ppc64 Howerver, building of ghc 7.6.3 with ghc 7.6.3 is looped. amatera+ 7318 77.5 0.4 259076 53692 ? Sl Aug17 587:14 /usr/lib/ghc/lib/ghc -B/usr/lib/ghc -M -dep-makefile compiler/stage1/build/.depend-v.haskell.tmp -include-pkg-deps -H32m -O -lffi -optl-pthread -optc-mminimal-toc -package-db libraries/bootstrapping.conf -package-name ghc-7.6.3 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/stage1 -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package Cabal-1.16.0 -package array-0.4.0.1 -package base-4.6.0.1 -package bin-package- db-0.0.0.0 -package bytestring-0.10.0.2 -package containers-0.5.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.1 -package hoopl-3.9.0.0 -package hpc-0.6.0.0 -package process-1.1.0.2 -package time-1.4.0.1 -package unix-2.6.0.1 -Wall -fno-warn-name-shadowing -fno- warn-orphans -XHaskell98 -XNondecreasingIndentation -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -DNO_REGS -DSTAGE=1 -no-user-package- db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -hisuf hi -osuf o -hcsuf hc compiler/basicTypes/Avail.hs compiler/basicTypes/BasicTypes.lhs compiler/basicTypes/DataCon.lhs compiler/basicTypes/Demand.lhs compiler/utils/Exception.hs compiler/main/GhcMonad.hs compiler/basicTypes/Id.lhs compiler/basicTypes/IdInfo.lhs compiler/basicTypes/Literal.lhs compiler/llvmGen/Llvm.hs compiler/llvmGen/Llvm/AbsSyn.hs compiler/llvmGen/Llvm/PpLlvm.hs compiler/llvmGen/Llvm/Types.hs compiler/llvmGen/LlvmCodeGen.hs compiler/llvmGen/LlvmCodeGen/Base.hs compiler/llvmGen/LlvmCodeGen/CodeGen.hs compiler/llvmGen/LlvmCodeGen/Data.hs compiler/llvmGen/LlvmCodeGen/Ppr.hs compiler/llvmGen/LlvmCodeGen/Regs.hs compiler/llvmGen/LlvmMangler.hs compiler/basicTypes/MkId.lhs compiler/basicTypes/Module.lhs compiler/basicTypes/Name.lhs compiler/basicTypes/NameEnv.lhs compiler/basicTypes/NameSet.lhs compiler/basicTypes/OccName.lhs compiler/basicTypes/RdrName.lhs compiler/basicTypes/SrcLoc.lhs compiler/basicTypes/UniqSupply.lhs compiler/basicTypes/Unique.lhs compiler/basicTypes/Var.lhs compiler/basicTypes/VarEnv.lhs compiler/basicTypes/VarSet.lhs compiler/cmm/BlockId.hs compiler/cmm/CLabel.hs compiler/cmm/Cmm.hs compiler/cmm/CmmBuildInfoTables.hs compiler/cmm/CmmPipeline.hs compiler/cmm/CmmCallConv.hs compiler/cmm/CmmCommonBlockElim.hs compiler/cmm/CmmContFlowOpt.hs compiler/cmm/CmmCvt.hs compiler/cmm/CmmExpr.hs compiler/cmm/CmmInfo.hs compiler/cmm/CmmLex.hs compiler/cmm/CmmLint.hs compiler/cmm/CmmLive.hs compiler/cmm/CmmMachOp.hs compiler/cmm/CmmNode.hs compiler/cmm/CmmOpt.hs compiler/cmm/CmmParse.hs compiler/cmm/CmmProcPoint.hs compiler/cmm/CmmRewriteAssignments.hs compiler/cmm/CmmSink.hs compiler/cmm/CmmType.hs compiler/cmm/CmmUtils.hs compiler/cmm/CmmLayoutStack.hs compiler/cmm/MkGraph.hs compiler/cmm/OldCmm.hs compiler/cmm/OldCmmLint.hs compiler/cmm/OldCmmUtils.hs compiler/cmm/OldPprCmm.hs compiler/nativeGen/PprBase.hs compiler/cmm/PprC.hs compiler/cmm/PprCmm.hs compiler/cmm/PprCmmDecl.hs compiler/cmm/PprCmmExpr.hs compiler/cmm/Bitmap.hs compiler/codeGen/CgBindery.lhs compiler/codeGen/CgCallConv.hs compiler/codeGen/CgCase.lhs compiler/codeGen/CgClosure.lhs compiler/codeGen/CgCon.lhs compiler/codeGen/CgExpr.lhs compiler/codeGen/CgExtCode.hs compiler/codeGen/CgForeignCall.hs compiler/codeGen/CgHeapery.lhs compiler/codeGen/CgHpc.hs compiler/codeGen/CgInfoTbls.hs compiler/codeGen/CgLetNoEscape.lhs compiler/codeGen/CgMon I don't know that there is relationship with this, buildings of Gtk2Hs package with ghc 7.6 have also looped on ppc64. http://buildd.debian-ports.org/status/logs.php?pkg=haskell-gtk&arch=ppc64 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8134#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. -------------------------------------+----------------------------- Reporter: k0da | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by k0da): I could provide an access to opensuse ppc64 box if needed for debugging issue. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8134#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. -------------------------------------+----------------------------- Reporter: k0da | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by Simon Peyton Jones ): In [changeset:8cfbdccb7f8716c2b6b13b3c7884f52b1087d782/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8cfbdccb7f8716c2b6b13b3c7884f52b1087d782" Accommodate Derived constraints in two places (fix Trac #8129, #8134) If we have class (F a ~ b) => C a b then we can produce *derived* CFunEqCans. These were not being treated properly in two places: a) in TcMType.zonkFlats (Trac #8134) b) in TcSMonad.prepareInertsForImplications (Trac #8129) This patch fixes both. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8134#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. -------------------------------------+----------------------------- Reporter: k0da | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by juhpetersen): The problem also happens on s390x. You can find some more details in the Fedora bug tracking this: https://bugzilla.redhat.com/show_bug.cgi?id=989593 Basically it looks like some kind of process lockup or race condition which seems to happen randomly during the above big "ghc -M -dep-makefile" invocation above. A subprocess has completed but somehow ghc is still hanging on it. {{{ 15692 pts/3 Ssl+ 3:37 /usr/lib64/ghc-7.6.3/ghc -B/usr/lib64/ghc-7.6.3 -optc-I/usr/include -v1 -M -dep-m 16531 pts/3 Z+ 0:00 \_ [gcc] <defunct> }}} There seems to be no systematic pattern - I didn't count the number of source files being preprocessed but it seems to happen each time quite some way into the processing of the files for me. gdb shows ghc is hung on {{{ #0 0x00000080c6c31ad0 in .pthread_cond_wait () from /lib64/libpthread.so.0 }}} Still not completely sure if this is a ghc or glibc issue or some conflict between them. Apparently the pthread handling on non-intel glibc is different from intel platforms. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8134#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. -------------------------------------+----------------------------- Reporter: k0da | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by juhpetersen): Replying to [comment:8 trommler]:

But we don't see the issue on PowerPC 32 bit, which is registerized and has a native code generator. PowerPC 64 is unregisterized.

Correct - nor on s390 which is also unregisterized. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8134#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. -------------------------------------+----------------------------- Reporter: k0da | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Changes (by gustavold): * cc: gustavold@… (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8134#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. -------------------------------------+----------------------------- Reporter: k0da | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Changes (by thoughtpolice): * status: new => patch -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8134#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. -------------------------------------+----------------------------- Reporter: k0da | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by Austin Seipp ): In [changeset:"a4b1a43542b11d09dd3b603d82c5a0e99da67d74/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a4b1a43542b11d09dd3b603d82c5a0e99da67d74" Fix loop on 64bit Big-Endian platforms (#8134) This is a fun one. In the RTS, `cas` expects a pointer to StgWord which will translate to unsigned long (8 bytes under LP64.) But we had previously declared token_locked as *StgBool* - which evaluates to 'int' (4 bytes under LP64.) That means we fail to provide enough storage for the cas primitive, causing it to corrupt memory on a 64bit platform. Hilariously, this somehow did not affect little-endian platforms (ARM, x86, etc) before. That's because to clear our lock token, we would say: token_locked = 0; But because token_locked is 32bits technically, this only writes to half of the 64bit quantity. On a Big-Endian machine, this won't do anything. That is, token_locked starts as 0: / token_locked | v 0x00000000 and the first cas modifies the memory to: / valid / corrupted | | v v 0x00000000 0x00000001 We then clear token_locked, but this doesn't change the corrupted 4 bytes of memory. And then we try to lock the token again, spinning until it is released - clearly a deadlock. Related: Windows (amd64) doesn't follow LP64, but LLP64, where both int and long are 4 bytes, so this shouldn't change anything on these platforms. Thanks to Reid Barton for helping the diagnosis. Also, thanks to Jens Peterson who confirmed this also fixes building GHC on Fedora/ppc64 and Fedora/s390x. Authored-by: Gustavo Luiz Duarte Signed-off-by: Austin Seipp }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8134#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. -------------------------------------+----------------------------- Reporter: k0da | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by simonpj): Amazing bug -- well done guys! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8134#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler