- ghc-tickets - Haskell.org

Re: [GHC] #3693: Show stack traces
by GHC 24 Jan '14

24 Jan '14

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by blitzcode): This is all quite tricky since there seem to be so many different approaches to consider! ;-) For profiling, I am mostly coming at this problem from the perspective of already having an external tool that works for C/C++ and wanting to add Haskell support to it (it's a sampling profiler, pausing threads and capturing their stack, as you already said). I think you make a very valid point about already having all the functionality in the RTS (eventually). I don't have any technical / ideological reason to prefer an external profiler, what I'm after is seeing profiling data in realtime, while the program is running. If the RTS is collecting profiling data it could either provide some kind of IPC API to have an external tool collect it, or maybe just have a Haskell API so one could use a library like EKG to show it to the user. I couldn't really figure out how the Haskell to C stack transition works, but I think that's a less common case than the Haskell to C one anyway. Glad to hear that the latter seems to be working! I don't agree that having an external program do a stack walk is necessarily complicated or awkward. With your DWARF3 work, one should be able to use something like libunwind-ptrace (http://www.nongnu.org/libunwind/man/libunwind-ptrace%283%29.html) and have that functionality available without any custom work. For debugging, I think there's merit for an external tool. For RTS exceptions we're ok, but as soon as we have an actual segfault, some memory corruption has often already taken place. Any kind of stack traversal, symbol lookup and error reporting code will have a decent chance of failing itself due to a corrupted heap or such. The only library that I can think of would be libunwind. It's supported on Linux/BSD, Apple ships some kind of version of it on OS X (there are some limitations / issues with their port, IIRC), does DWARF2/3. It's not on Windows, but there's build-in support for stack walking through the DbgHelp library (StackWalk64, no idea if Windows PDB debug information supports the kind of wizardry your using to explain the STG stack to a DWARF3 debugger, though). It seems generating the right kind of debug symbols, and supporting and doing stack walking for Haskell & C/C++ on all three platforms is a major challenge... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:57> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5144: Pattern synonyms
by GHC 24 Jan '14

24 Jan '14

#5144: Pattern synonyms -------------------------------------------+------------------------------- Reporter: simonpj | Owner: cactus Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8581, 8582, 8583, 8584 | Blocked By: | Related Tickets: -------------------------------------------+------------------------------- Comment (by cactus): OK, will fix `7.8.1-notes.xml`. Just to avoid any misunderstandings, I've already added a section to `glasgow_exts.xml`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5144#comment:46> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell
by GHC 24 Jan '14

24 Jan '14

#7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by goldfire): Thanks for sharing your patch. Here are some further comments: * The `EqualityT` constructor has type `Type -> Type -> Type`. Yet, this would prevent encoding constructs like `[t| ((~) Int) |]`, which should be valid. I recommend putting `EqualityT` in like `ArrowT` is now, as a nullary (0-argument) constructor. * The `foldM` and `go` algorithm (lines 65-67) you use seems like `repTapps`. Or, am I missing something? * In reifying an `IrredPred`, you use `splitAppTy`... but we're not sure there that the type is an application. For example, it could be a nullary type family, like this: {{{ type family ALittleSilly :: Constraint }}} I believe this would be an `IrredPred`, if there are no instances for the type family. (I haven't tested it.) I will say that I appreciate your attention to detail to GHC's coding style. I hope all these comments don't put you off -- we do really appreciate your contribution! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7021#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2450: Data.Complex.magnitude squares using ^(2 :: Int), which is slow
by GHC 23 Jan '14

23 Jan '14

#2450: Data.Complex.magnitude squares using ^(2 :: Int), which is slow --------------------------------------------+------------------------------ Reporter: igloo | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: libraries/base | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by monoidal): * status: new => closed * resolution: => fixed Comment: You are right, I see that originally the bug was left open because of missing rewrite rules (https://github.com/ghc/packages- base/commit/d6adf6bd595c3b8f750acc9293f5847f176b521b) but they were added in #5237. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2450#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8692: when reporting missing modules, report them all at once
by GHC 23 Jan '14

23 Jan '14

#8692: when reporting missing modules, report them all at once ------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently, when a module is missing I get the message: {{{ Main.hs:6:18: Could not find module `Data.StorableVector.Base' It is a member of the hidden package `storablevector-0.2.8'. Perhaps you need to add `storablevector' to the build-depends in your .cabal file. It is a member of the hidden package `storablevector-0.2.8.1'. Perhaps you need to add `storablevector' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. }}} In order to solve the problem I add the package name to the Cabal file as suggested. However, if many modules are missing, then it becomes tedious to add every package individually and recompile with Cabal. It would be great if GHC shows _all_ missing modules and their according packages. This helps a lot when converting from the old Cabal style "recompile all library modules for an executable" to the new style "import the main library for every executable". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8692> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #2450: Data.Complex.magnitude squares using ^(2 :: Int), which is slow
by GHC 23 Jan '14

23 Jan '14

#2450: Data.Complex.magnitude squares using ^(2 :: Int), which is slow --------------------------------------------+------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: libraries/base | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by cdk): It looks like this has been resolved, `Data.Complex.magnitude` now uses `sqr z = z * z` and `GHC.Real` has rewrite rules for small, known constant exponents: https://github.com/ghc/packages-base/blob/master/Data/Complex.hs https://github.com/ghc/packages-base/blob/master/GHC/Real.lhs I found this bug on the list of 'getting started' bugs, but it's already been fixed. Time to close? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2450#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5144: Pattern synonyms
by GHC 23 Jan '14

23 Jan '14

#5144: Pattern synonyms -------------------------------------------+------------------------------- Reporter: simonpj | Owner: cactus Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8581, 8582, 8583, 8584 | Blocked By: | Related Tickets: -------------------------------------------+------------------------------- Comment (by monoidal): Just a section in `docs/users_guide/glasgow_exts` should be enough. Release notes are in `docs/users_guide/7.8.1-notes.xml`; Austin added the entry for pattern synonyms, you might expand it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5144#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3693: Show stack traces
by GHC 23 Jan '14

23 Jan '14

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by scpmw): > Unified code for symbol lookup (no more Win32 Sym* APIs vs Linux addr2line vs OS X / BSD atos) As far as the current design goes, we already read out the symbol and DWARF tables of all loaded executable sections. So by going through the RTS you'd have that part covered as well (well, at least for Linux). See [https://github.com/scpmw/ghc/blob/profiling-ncg/rts/Dwarf.c Dwarf.c]. > Mostly for profiling, where we'd like to inspect the program hundreds or even thousands of times per second with as little overhead as possible. I suppose you are talking about an external sampling routine that walks the stack in certain intervals? My approach would have been to try to do that in the RTS, but this might work as well. > Peter, do your DWARF improvements handle FFI calls (traversing from C back into Haskell)? I saw it work at least once - and when in doubt, the machinery for generating DWARF unwind from Cmm is flexible enough that there is probably a way to make it work if it doesn't already. Going from Haskell back to C is probably trickier. Bottom line is that even with with the points you mention, I am still a fan of the "leave it to the RTS"-approach. My main reason is that we already have (and need) quite a bit of functionality in the RTS, so having an external program re-implement stack walking and symbol lookup seems awkward to me. So maybe the solution here is to make the RTS more powerful. Could it be a possibility to use the mentioned libraries to displace libdwarf in the RTS? It's already a somewhat uncommon dependency, so if the switch would buy us unwinding of the C stack and better portability, it might work out quite nicely. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:56> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2283: WIndows: loading objects that refer to DLL symbols
by GHC 23 Jan '14

23 Jan '14

#2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------- Comment (by awson): Not quite understood. ''a reference to the ticket in the comment...'' do you mean a source code comment? ''a sentence or two describing the problem...'' this should go to source code too? or to a comment to this ticket? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2283#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2283: WIndows: loading objects that refer to DLL symbols
by GHC 23 Jan '14

23 Jan '14

#2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------- Comment (by simonmar): Please add a reference to the ticket in the comment, and if you could add a sentence or two describing the problem (or a pointer to somewhere else that describes it) that would be really helpful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2283#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0