Re: [GHC] #2542: runghc does not infer module file extensions
#2542: runghc does not infer module file extensions --+- Reporter: judah | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler |Version: 6.8.3 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Comment (by simonmar): Yes, the change was deliberate, but I agree it's not ideal and we should try to fix it. I just don't know what to do about it. The problem is that people wanted a way to say load this file with the interpreter only, ignore any compiled code for it. And the solution we adopted for this was to say that any target named by ''filename'' (rather than ''module'') would be loaded with the interpreter. But the problem is that previously `:load Setup` would look for a filename `Setup.hs` and load that, but that's wrong: we don't want `:load Setup` to always use the interpreter. So I made `:load Setup` treat `Setup` as a module name, which seems more correct. The problem is that now `:load Setup` will expect to find a module called `Setup` when it reads `Setup.hs`, which it often won't. So I could probably add an exception for this case and make it work again, but it would be ugly, and hard to document without being thoroughly confusing. Can anyone think of a plan that is simple, easy to explain and implement, and doesn't break existing practice too much? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2542#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2542: runghc does not infer module file extensions
#2542: runghc does not infer module file extensions --+- Reporter: judah | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler |Version: 6.8.3 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Comment (by igloo): Can `Foo` not search for `Foo.ohi`, then `Foo.hs`, then `Foo.lhs`, and not require that the module name matches? `foo` would do the same. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2542#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2520: SPECIALIZE causing duplicate assembler symbols
#2520: SPECIALIZE causing duplicate assembler symbols --+- Reporter: ganesh| Owner: simonpj Type: bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.9 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: x86 Os: Linux | --+- Changes (by simonpj): * owner: = simonpj * difficulty: = Unknown Comment: I'll look at this. See also #2543 Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2520#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2543: Nested SPECIALIZEd functions cause error: Symbol _BadUTF8_zdf1_closure already defined.
#2543: Nested SPECIALIZEd functions cause error: Symbol _BadUTF8_zdf1_closure already defined. --+- Reporter: judah | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Compiler |Version: 6.9 Severity: normal| Resolution: duplicate Keywords:| Difficulty: Unknown Testcase:| Architecture: x86 Os: MacOS X | --+- Changes (by simonpj): * status: new = closed * difficulty: = Unknown * resolution: = duplicate Comment: Dup of #2520. Thanks for another test case. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2543#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2337: Data.Array documentation utterly broken
#2337: Data.Array documentation utterly broken ---+ Reporter: japple | Owner: Type: bug| Status: reopened Priority: normal | Milestone: 6.10.1 Component: Documentation |Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown| ---+ Comment (by simonmar): A quick fix for 6.10.1 would be to un-hide `GHC.Arr`, then at least we'd get hyperlinks in the `Data.Array` docs that would take you to the actual documentation. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2337#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2542: runghc does not infer module file extensions
#2542: runghc does not infer module file extensions --+- Reporter: judah | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler |Version: 6.8.3 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Comment (by simonmar): Yes, but that would be an exception. There are currently two cases: * a module name: search for the source file using the normal search semantics (`-i` search path, hierarchical module names etc.), load compiled code if available, require the module name in the file to be correct. * a filename ending in `.hs` or `.lhs`, or missing the extension: load exactly that file, which can contain any module, and in GHCi ignore any compiled version. there would be an extra case, to come first: * for target `X`, if `X.hs` or `X.lhs` exists, load that file, which can contain any module, and in GHCi load compiled code if available. this would change the behaviour of `:load foo` (it would load compiled code, whereas `:load foo.hs` wouldn't). My main objection to this is that three cases feels like one too many to me. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2542#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2542: runghc does not infer module file extensions
#2542: runghc does not infer module file extensions --+- Reporter: judah | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler |Version: 6.8.3 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by igloo): * owner: igloo = -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2542#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2485: Installed ghci wrapper refers to nonexistent file
#2485: Installed ghci wrapper refers to nonexistent file --+- Reporter: judah | Owner: igloo Type: bug | Status: closed Priority: normal| Milestone: 6.10.1 Component: Compiler |Version: 6.9 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Testcase:| Architecture: x86 Os: MacOS X | --+- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Thanks for the report; now fixed. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2485#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2513: Bad location info for flag warnings
#2513: Bad location info for flag warnings
---+
Reporter: Feuerbach | Owner: igloo
Type: bug| Status: new
Priority: normal | Milestone:
Component: Compiler |Version: 6.9
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown|
---+
Comment (by simonpj):
I've realised that good location info for flag warnings is more important
than I thought when you are using `--make` or compiling multiple modules.
Below is a dump from building GHC itself. Saying `no location info`
does not tell me which module has the offending pragma; or whether it's
the command line. (In this case it's the latter.)
{{{
/64playpen/simonpj/builds/HEAD-1/ghc/stage1-inplace/ghc -M -dep-makefile
dist-stage2/build/.depend -package-name ghc-6.9 -hide-all-packages -no-
user-package-conf -i -idist-stage2/build -inativeGen -ibasicTypes -icmm
-icodeGen -icoreSyn -icprAnalysis -ideSugar -ighci -ihsSyn -iiface -imain
-iparser -iprelude -iprofiling -irename -isimplCore -isimplStg
-ispecialise -istgSyn -istranal -itypecheck -itypes -iutils -ivectorise
-idist-stage2/build/autogen -Idist-stage2/build/autogen -Idist-
stage2/build -I../libffi/build/include -Istage2plus
-I../libraries/base/cbits -I../libraries/base/include -I. -Iparser -Iutils
-optP-DUSE_EDITLINE -optP-DGHCI -optP-include -optPdist-
stage2/build/autogen/cabal_macros.h -odir dist-stage2/build -hidir dist-
stage2/build -stubdir dist-stage2/build -package Cabal-1.5.3 -package
array-0.1 -package base-4.0 -package bytestring-0.9 -package
concurrent-0.1 -package containers-0.1 -package directory-1.0 -package
editline-0.2 -package filepath-1.1 -package haskell98-1.0.1 -package
hpc-0.5 -package old-time-1.0 -package process-1.0.1 -package st-0.1
-package template-haskell-2.2 -package unix-2.2 -O
-DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Wall -fno-warn-name-shadowing -fno-
warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards
-XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances
-XMultiParamTypeClasses -XFlexibleInstances -XRank2Types
-XPatternSignatures -idist-stage2/build -Werror -H64m -O0 -fasm -Rghc-
timing -O0 -fasm AsmCodeGen MachCodeGen MachInstrs MachRegs NCGMonad
PositionIndependentCode PprMach RegAllocColor RegAllocInfo RegAllocLinear
RegAllocStats RegArchBase RegArchX86 RegCoalesce RegLiveness RegSpill
RegSpillClean RegSpillCost DsMeta TcSplice Convert ByteCodeAsm ByteCodeFFI
ByteCodeGen ByteCodeInstr ByteCodeItbls ByteCodeLink Debugger GhciMonad
GhciTags InteractiveUI LibFFI Linker ObjLink RtClosureInspect BasicTypes
DataCon Demand Exception Id IdInfo Literal MkId Module Name NameEnv
NameSet NewDemand OccName RdrName SrcLoc UniqSupply Unique Var VarEnv
VarSet BlockId CLabel Cmm CmmBrokenBlock CmmCPS CmmCPSGen CmmCPSZ
CmmCallConv CmmCommonBlockElimZ CmmContFlowOpt CmmCvt CmmExpr CmmInfo
CmmLex CmmLint CmmLive CmmLiveZ CmmOpt CmmParse CmmProcPoint CmmProcPointZ
CmmSpillReload CmmTx CmmUtils CmmZipUtil DFMonad Dataflow MachOp MkZipCfg
MkZipCfgCmm OptimizationFuel PprC PprCmm PprCmmZ StackColor
StackPlacements ZipCfg ZipCfgCmmRep ZipCfgExtras ZipDataflow Bitmap
CgBindery CgCallConv CgCase CgClosure CgCon CgExpr CgForeignCall CgHeapery
CgHpc CgInfoTbls CgLetNoEscape CgMonad CgParallel CgPrimOp CgProf
CgStackery CgTailCall CgTicky CgUtils ClosureInfo CodeGen SMRep CoreFVs
CoreLint CorePrep CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils
ExternalCore MkCore MkExternalCore PprCore PprExternalCore CprAnalyse
Check Coverage Desugar DsArrows DsBinds DsCCall DsExpr DsForeign DsGRHSs
DsListComp DsMonad DsUtils Match MatchCon MatchLit HsBinds HsDecls HsDoc
HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils BinIface BuildTyCl
IfaceEnv IfaceSyn IfaceType LoadIface MkIface TcIface BreakArray
CmdLineParser CodeOutput Config Constants DriverMkDepend DriverPhases
DriverPipeline DynFlags ErrUtils Finder GHC HeaderInfo HscMain HscStats
HscTypes InteractiveEval PackageConfig Packages ParsePkgConf PprTyThing
StaticFlags SysTools TidyPgm Ctype HaddockLex HaddockParse HaddockUtils
LexCore Lexer Parser ParserCore ParserCoreUtils RdrHsSyn ForeignCall
PrelInfo PrelNames PrelRules PrimOp TysPrim TysWiredIn CostCentre SCCfinal
RnBinds RnEnv RnExpr RnHsDoc RnHsSyn RnNames RnPat RnSource RnTypes CSE
FloatIn FloatOut LiberateCase OccurAnal SAT SetLevels SimplCore SimplEnv
SimplMonad SimplUtils Simplify SRT SimplStg StgStats Rules SpecConstr
Specialise CoreToStg StgLint StgSyn DmdAnal SaAbsInt SaLib StrictAnal
WorkWrap WwLib FamInst Inst TcArrows TcBinds TcClassDcl TcDefaults TcDeriv
TcEnv TcExpr TcForeign TcGenDeriv TcHsSyn TcHsType TcInstDcls TcMType
TcMatches TcPat TcRnDriver TcRnMonad TcRnTypes
Re: [GHC] #2542: runghc does not infer module file extensions
#2542: runghc does not infer module file extensions --+- Reporter: judah | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler |Version: 6.8.3 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Comment (by simonpj): I thought that we allowed the module name not to match the file name precisely (and only) when the module was called `Main`. That would collapse your first and third bullets which is what you wanted. Also I suggest that plain `M` (no suffix) on the command line should fail altogether if you can't find `M.hs` or `M.lhs`, regardless of whether you are linking or not. And plain `m` (lower case) should fail too, since `m` can't be a module name. Stuff you want to link should have suffix `.o` or `.a`, shouldn't it? Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2542#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2542: runghc does not infer module file extensions
#2542: runghc does not infer module file extensions --+- Reporter: judah | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler |Version: 6.8.3 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Comment (by claus): (aside: would either `runhaskell Main` or adding `module Setup where` work?) The first two cases sound right overall, but note that they already differ in strictness of checking: - via module name, the file name has to match - via file name, the module name doesn't need to match. It would make more sense to have matching behaviour determined independently of the route, but the module-name route depends on strict matches to find the file (or ghc would have to check all sources for matching module names). We could still have a flag `ModuleFileNameMatch`, but it wouldn't buy much. The problem arises from `Setup.[l]hs` '''not''' having a module name, combined with the default being `Main`, which was meant to make finding and running `Main.main` in non-module code possible, while Cabal wants to find and run `Setup.main` in non-module code. Could we simply change the default module name? - if the filename is a module name, `File.[l]hs` introduces module `File` (and module `Main`, if we still need that?) - if there is an explicit module name, it has to match the file name or be `Main` -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2542#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #2544: Improve Can't unify error messages from type functions
#2544: Improve Can't unify error messages from type functions
+---
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.12 branch
Component: Compiler (Type checker) | Version: 6.8.3
Severity: normal |Keywords:
Difficulty: Unknown |Testcase:
Architecture: Unknown | Os: Unknown
+---
Consider this example from a Haskell Cafe thread:
{{{
data (:|:) a b = Inl a | Inr b
class Ix i where
type IxMap i :: * - *
empty :: IxMap i [Int]
data BiApp a b c = BiApp (a c) (b c)
instance (Ix l, Ix r) = Ix (l :|: r) where
type IxMap (l :|: r) = BiApp (IxMap l) (IxMap r)
empty = BiApp empty empty
}}}
This elicits the following confusing error message:
{{{
Couldn't match expected type `IxMap l'
against inferred type `IxMap i'
Expected type: IxMap (l :|: r) [Int]
Inferred type: BiApp (IxMap i) (IxMap i1) [Int]
In the expression: BiApp empty empty
In the definition of `empty': empty = BiApp empty empty
}}}
As Alexander Dunlap responds, the error message is correct, but I can't
help feeling that we should try harder to give a better error message.
Something like Since `IxMap` is a type function, knowing that `IxMap l` =
`IxMap i` does not require that `l` = `i`. Or something.
This ticket is just to make sure we don't forget. The thread is here
http://www.haskell.org/pipermail/haskell-cafe/2008-August/046371.html
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2544
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2497: Weird scoping for tyvars in rules
#2497: Weird scoping for tyvars in rules
+---
Reporter: rl | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler|Version: 6.8.3
Severity: normal | Resolution: fixed
Keywords: | Difficulty: Unknown
Testcase: typecheck/should_compile/T2497 | Architecture: Unknown
Os: Unknown |
+---
Changes (by simonpj):
* testcase: = typecheck/should_compile/T2497
* status: new = closed
* resolution: = fixed
Comment:
Fixed by a combination of
{{{
Wed Aug 20 14:29:11 BST 2008 Simon Marlow [EMAIL PROTECTED]
* always treat 'forall' and '.' as reserved keywords inside RULES
pragmas
}}}
and
{{{
Tue Aug 26 13:21:21 BST 2008 [EMAIL PROTECTED]
* Fix flaggery for RULES (cf Trac #2497)
}}}
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2497#comment:6
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2538: Better error message for missing Rank2Types (or RankNTypes) flag
#2538: Better error message for missing Rank2Types (or RankNTypes) flag -+-- Reporter: tim | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) |Version: 6.8.2 Severity: minor| Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -+-- Changes (by simonpj): * owner: = simonpj * difficulty: = Unknown Comment: Good idea. I'm fixing this. S -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2538#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #2545: Data Parallel Haskell on Kubuntu 8.04 uses too much memory
#2545: Data Parallel Haskell on Kubuntu 8.04 uses too much memory
+---
Reporter: jjanssen | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 6.8.3|Severity: normal
Keywords: Memory Leak |Testcase:
Architecture: x86 | Os: Linux
+---
Hey.
I tried to perform some tests on the performance of data parallel haskell
today using the program from the DPH-wiki:
{{{
{-# OPTIONS -fparr -fglasgow-exts #-}
module Main
where
import GHC.PArr
dotp :: Num a = [:a:] - [:a:] - a
dotp xs ys = sumP [:x*y | x - xs | y - ys:]
main = putStrLn $ show $ dotp [:1..50:] [:5..495:]
}}}
After compiling this with -threaded and running it, the memory usage
starts to increase up until the point that the machine starts swapping.
On a machine with 2GiB of memory, this hardly seems to be normal
behaviour, especially since a program like this should presumably take up
maximally 3*the size of the vectors used, which would translate to
3*500.000*32 bit = 6MiB. So this seems like a bug.
I tried it with the GHC 6.8.2 that is in the kubuntu repositories and with
the GHC 6.8.3 binaries distributed on the GHC website. Both showed the
same behaviour. Also, the behaviour does not seem to depend on the usage
of +RTS -N2, as both with and without these flags the memory gets filled.
Additionally, I remember having similar problems when trying out parMap_
on an example, but I can't seem to find the example right now.
Hopefully this gets fixed (or maybe already is), so I can start using the
power of DPH to optimise some of my programs.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2545
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1346: bootstrap from HC files
#1346: bootstrap from HC files --+- Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Build System |Version: 6.6.1 Severity: normal| Resolution: Keywords:| Difficulty: Moderate (1 day) Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by simonpj): * milestone: 6.10.1 = 6.12 branch Comment: Let's postpone this past the 6.10 release, because the build system is in upheaval. Simon Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1346#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2462: Data.List.sum is slower than 6.8.3
#2462: Data.List.sum is slower than 6.8.3 --+- Reporter: simonmar | Owner: simonpj Type: run-time performance bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler |Version: 6.8.3 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by simonpj): * owner: = simonpj -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2462#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #2546: Reliable crash in scheduleCheckBlackHoles
#2546: Reliable crash in scheduleCheckBlackHoles
---+
Reporter: nogin | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 6.8.2 |Severity: critical
Keywords: crash |Testcase:
Architecture: x86 | Os: Linux
---+
I hit a fully reproducible bug in {{{scheduleCheckBlackHoles}}} using GHC
6.8.2 under CentOS 5.2. The program has no FFI and no unsafe calls. Before
reporting the bug, I've deleted all the binaries and recompiled using
{{{ghc -Wall -Werror -fwarn-simple-patterns -fwarn-tabs -fwarn-incomplete-
record-updates -fwarn-monomorphism-restriction -fno-warn-name-shadowing
-threaded -O2 -dcore-lint -o XXX YYY/*.hs}}}. I run with {{{+RTS -N3 -A10m
-sstderr}}}. The {{{gdb}}} output is given below.
P.S. The code in question is unfortunately proprietary and I doubt that
I'd be able to share a test case. The code is very heavy on IORefs
(including lots and lost of atomicModifyIORef) and uses a number of MVars
(the model is - use atomicModifyIORef if possible; then use an MVar if
atomicModifyIORef's output suggests we may need to block), but no STM.
P.P.S. I'd be more than happy to help in debugging, if somebody is willing
to provide guidance (I am fairly new to Haskell, but have 10+ years of in-
depth OCaml experience).
{{{
(gdb) run 4000 +RTS -N3 -A10m -sstderr
Starting program: XXX 4000 +RTS -N3 -A10m -sstderr
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
XXX 4000 +RTS -N3 -A10m -sstderr
[New Thread 1118336 (LWP 20985)]
[New Thread 24583056 (LWP 21019)]
[New Thread 86469520 (LWP 21020)]
[New Thread 59771792 (LWP 21021)]
[New Thread 117144464 (LWP 21022)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 59771792 (LWP 21021)]
0x080884b3 in scheduleCheckBlackHoles ()
(gdb) run 4000 +RTS -N3 -A10m -sstderr
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: XXX 4000 +RTS -N3 -A10m -sstderr
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
XXX 4000 +RTS -N3 -A10m -sstderr
[New Thread 1118336 (LWP 21029)]
[New Thread 24963984 (LWP 21061)]
[New Thread 68045712 (LWP 21062)]
[New Thread 78535568 (LWP 21063)]
[New Thread 89025424 (LWP 21064)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 78535568 (LWP 21063)]
0x080884b3 in scheduleCheckBlackHoles ()
(gdb) bt
#0 0x080884b3 in scheduleCheckBlackHoles ()
#1 0x0a0d1f34 in ?? ()
#2 0x0004 in ?? ()
#3 0x0001 in ?? ()
#4 0x0a0bf0d8 in ?? ()
#5 0x0001 in ?? ()
#6 0x08089497 in schedule ()
#7 0x0a0d1ee8 in ?? ()
#8 0x0001ff78 in ?? ()
#9 0x in ?? ()
(gdb) run 4000 +RTS -N3 -A10m -sstderr
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: XXX 4000 +RTS -N3 -A10m -sstderr
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
XXX 4000 +RTS -N3 -A10m -sstderr
[New Thread 1118336 (LWP 21065)]
[New Thread 26430352 (LWP 21097)]
[New Thread 36920208 (LWP 21098)]
[New Thread 130771856 (LWP 21099)]
[New Thread 47410064 (LWP 21100)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 26430352 (LWP 21097)]
0x080884b3 in scheduleCheckBlackHoles ()
(gdb) bt
#0 0x080884b3 in scheduleCheckBlackHoles ()
#1 0x0977a4d4 in ?? ()
#2 0x0004 in ?? ()
#3 0x0001 in ?? ()
#4 0x0976e1f8 in ?? ()
#5 0x0001 in ?? ()
#6 0x08089497 in schedule ()
#7 0x0977a488 in ?? ()
#8 0x1f78 in ?? ()
#9 0x0005 in ?? ()
#10 0x080bca50 in stg_NO_TREC_closure ()
#11 0x0977a4d4 in ?? ()
#12 0x0976e1f8 in ?? ()
#13 0x07126000 in ?? ()
#14 0x1000 in ?? ()
#15 0x01934b5c in ?? ()
#16 0x07126000 in ?? ()
#17 0x0977a4d4 in ?? ()
#18 0x0977a488 in ?? ()
#19 0x0976e1f8 in ?? ()
#20 0x0976e1f8 in ?? ()
#21 0x0977a4d4 in ?? ()
#22 0x0977a488 in ?? ()
#23 0x0976e1f8 in ?? ()
#24 0x019344b8 in ?? ()
#25 0x08089b24 in workerStart ()
#26 0x080bdbdc in dummy_tso ()
#27 0x0977a488 in ?? ()
#28 0x in ?? ()
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2546
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2546: Reliable crash in scheduleCheckBlackHoles
#2546: Reliable crash in scheduleCheckBlackHoles
-+--
Reporter: nogin |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 6.8.2
Severity: critical | Resolution:
Keywords: crash | Testcase:
Architecture: x86 | Os: Linux
-+--
Comment (by nogin):
By adding the {{{-debug -dppr-debug}}} flags to the compilation command
line, I was able to get a much better {{{gdb}}} backtrace:
{{{
(gdb) run 4000 +RTS -N3 -A10m -sstderr
Starting program: XXX 4000 +RTS -N3 -A10m -sstderr
[Thread debugging using libthread_db enabled]
XXX 4000 +RTS -N3 -A10m -sstderr
[New Thread 1118336 (LWP 21542)]
[New Thread 25070480 (LWP 21576)]
[New Thread 113068944 (LWP 21577)]
[New Thread 85584784 (LWP 21578)]
[New Thread 131009424 (LWP 21579)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 131009424 (LWP 21579)]
0x0808c25c in checkBlackHoles (cap=0x8daf278) at Schedule.c:2952
2952Schedule.c: Нет такого файла или каталога.
in Schedule.c
(gdb) bt
#0 0x0808c25c in checkBlackHoles (cap=0x8daf278) at Schedule.c:2952
#1 0x0808a5b5 in scheduleCheckBlackHoles (cap=0x8daf278) at
Schedule.c:941
#2 0x0808983a in schedule (initialCapability=0x8daf278, task=0x8dc4268)
at Schedule.c:458
#3 0x0808b957 in workerStart (task=0x8dc4268) at Schedule.c:2528
#4 0x00d5f46b in start_thread () from /lib/libpthread.so.0
#5 0x00cb6dbe in clone () from /lib/libc.so.6
(gdb) run 4000 +RTS -N3 -A10m -sstderr
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: XXX 4000 +RTS -N3 -A10m -sstderr
[Thread debugging using libthread_db enabled]
XXX 4000 +RTS -N3 -A10m -sstderr
[New Thread 1118336 (LWP 21588)]
[New Thread 25312144 (LWP 21620)]
[New Thread 62921616 (LWP 21621)]
[New Thread 103971728 (LWP 21622)]
[New Thread 73411472 (LWP 21623)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 25312144 (LWP 21620)]
0x0808c25c in checkBlackHoles (cap=0x8787278) at Schedule.c:2952
2952in Schedule.c
(gdb) bt
#0 0x0808c25c in checkBlackHoles (cap=0x8787278) at Schedule.c:2952
#1 0x0808a5b5 in scheduleCheckBlackHoles (cap=0x8787278) at
Schedule.c:941
#2 0x0808983a in schedule (initialCapability=0x8787278, task=0x8793578)
at Schedule.c:458
#3 0x0808b957 in workerStart (task=0x8793578) at Schedule.c:2528
#4 0x00d5f46b in start_thread () from /lib/libpthread.so.0
#5 0x00cb6dbe in clone () from /lib/libc.so.6
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2546#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2546: Reliable crash in checkBlackHoles
#2546: Reliable crash in checkBlackHoles -+-- Reporter: nogin |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.8.2 Severity: critical | Resolution: Keywords: crash | Testcase: Architecture: x86 | Os: Linux -+-- Changes (by nogin): * summary: Reliable crash in scheduleCheckBlackHoles = Reliable crash in checkBlackHoles -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2546#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2546: Reliable crash in checkBlackHoles
#2546: Reliable crash in checkBlackHoles -+-- Reporter: nogin |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.8.2 Severity: critical | Resolution: Keywords: crash | Testcase: Architecture: x86 | Os: Linux -+-- Comment (by nogin): This might be a dup of #1898 - will try upgrading to 6.8.3 to check if it's still there. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2546#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1895: Allow aliases in GHCi module imports
#1895: Allow aliases in GHCi module imports -+-- Reporter: tibbe| Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi |Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -+-- Changes (by jcpetruzza): * cc: [EMAIL PROTECTED] (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1895#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #2547: No -X flag for unboxed types
#2547: No -X flag for unboxed types
+---
Reporter: tim | Owner:
Type: feature request | Status: new
Priority: normal | Component: Compiler
Version: 6.8.3|Severity: minor
Keywords: |Testcase:
Architecture: Unknown | Os: Unknown
+---
There doesn't seem to be a separate -X flag for unboxed types; there is
one for unboxed tuples, but it seems like {{{Int#}}}, {{{Char#}}} and the
rest can only be gotten at with {{{-fglasgow-exts}}}.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2547
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2547: No -X flag for unboxed types
#2547: No -X flag for unboxed types +--- Reporter: tim |Owner: Type: feature request | Status: new Priority: normal |Milestone: Component: Compiler | Version: 6.8.3 Severity: minor| Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown +--- Comment (by NeilMitchell): -XMagicHash is the answer. I have no idea where the documentation is, and neither does Google... -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2547#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1895: Allow aliases in GHCi module imports
#1895: Allow aliases in GHCi module imports -+-- Reporter: tibbe| Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi |Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -+-- Changes (by guest): * cc: [EMAIL PROTECTED] (added) Comment: Speaking for myself, I really hope that when this is fixed, it'll be easy to load modules qualified via the GHC API. This would let me fix mueval so things like 'mueval -e Map.map (+1) $ Map.fromList [(1,2)]' could work. (Which is valuable since I use mueval in Lambdabot, and Lambdabot users expect to be able to use qualified imports.) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1895#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1895: Allow aliases in GHCi module imports
#1895: Allow aliases in GHCi module imports -+-- Reporter: tibbe| Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi |Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -+-- Changes (by guest): * cc: [EMAIL PROTECTED] (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1895#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2547: No -X flag for unboxed types
#2547: No -X flag for unboxed types +--- Reporter: tim |Owner: Type: feature request | Status: new Priority: normal |Milestone: Component: Documentation| Version: 6.8.3 Severity: minor| Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown +--- Comment (by duncan): Replying to [comment:1 NeilMitchell]: -XMagicHash is the answer. I have no idea where the documentation is, and neither does Google... I should like to note that I am now enforcing that all new language extensions registered in Language.Haskell.Extension require haddock documentation including an explanation and examples. Ian was the first victim of my enforcement earlier today when he registered the `PackageImports` extension. :-) Hopefully this will help google and hoogle and become a useful reference. Obviously this will require copying out documentation from various places for all the existing extensions. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2547#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2545: Data Parallel Haskell on Kubuntu 8.04 uses too much memory
#2545: Data Parallel Haskell on Kubuntu 8.04 uses too much memory +--- Reporter: jjanssen |Owner: Type: bug | Status: closed Priority: normal |Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: Memory Leak | Testcase: Architecture: x86 | Os: Linux +--- Changes (by chak): * status: new = closed * resolution: = invalid Comment: Data Parallel Haskell is not supported at all in the 6.8.x branch and the version that you have been testing is just a very, very rough prototype to play around with the surface syntax. It does not run in parallel at all and there is no optimisation whatsoever. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2545#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
