November 2013 - ghc-tickets

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 11 Nov '13

11 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 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 duncan): So on reflection, I think I'm changing my opinion. The H2010 docs say: "The exact interpretation of the code is operating- system dependent." So on that principle then I think we're well justified to use a reasonable encoding. This also means we don't have the trouble of braking existing code by adding a new `ExitCode` constructor. Existing code that doesn't interpret the exit code much will continue to work. As for the specific encoding. It would be madness for us to use the low bits for the signal. There must be plenty of code out there that looks for `ExitFailure 1` or other low numbers for example. So we would have to use Simon's encoding, high bits for a signal, low bits for a normal exit. I suggest we update the `ExitCode` docs to indicate how the `Int` corresponds to the system exit code on Windows and Unix (ie directly for Windows and the high 8 signal & low 8 normal exit code encoding for Unix). hvr raises a related question: * What should we do for `exitWith (ExitFailure n)` for `n > 255` on Unix? Currently the code just takes the low 8 bits. This is clearly silly since it would end up being equiv to `exitWith ExitSuccess`. Using numbers > 255 is fine on Windows. In addition, if we are going to use 16 bits for the exit code on Unix then we ought to be able to use `exitWith` on such values. So, how about this for a specific suggestion: * On unix, use 16bits of the `ExitFailure Int`, high 8 for signal, low 8 for normal exit code. * `waitForProcess` & `getProcessExitCode` return this encoding on Unix. * It is valid to `exitWith` an `ExitCode` from `waitForProcess` & `getProcessExitCode` and the top level handler should make this have the appropriate behaviour: * calling exit(n); or * calling kill(getpid(), s); * These are mutually exclusive. That is, we either get non-0 high byte or non-0 low byte but never both. * We enforce this on the `exitWith` side. An invalid encoding is replaced with `ExitFailure 255`. So that's used if both exit code + signal are set, or if it's > 16bit, or negative. But we do not make it an error because we don't want to create needless portability problems for programs using high Windows error codes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 11 Nov '13

11 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 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 andersk): I guess you could replace `ExitTerminated CInt Bool` with `ExitTerminated Signal Bool`, where `Signal` is `CInt` on POSIX and `Void` on Windows? (And/or there’s a platform-independent `Signal -> CInt` and a POSIX- dependent `CInt -> Signal`?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 11 Nov '13

11 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 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 duncan): What would `exitWith (ExitTerminated signal)` mean on Windows? Having the abstract `ExitStatus` type as Simon and I proposed would not have that issue, since it's only for the reading side, not the throwing side, and on Windows can always return Nothing. My view is still that using a structured type is a lot nicer than using a bit twiddling encoding. Related to this is that we want an extra `CreateProcess` option to do the WCE automatically. We still have the mad situation that System.Cmd can mask ctl-c for us, but System.Process lacks that feature. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8513: Parallel GC increases CPU load while slowing down program
by GHC 11 Nov '13

11 Nov '13

#8513: Parallel GC increases CPU load while slowing down program ------------------------------+-------------------------------------------- Reporter: blitzcode | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.6.3 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I noticed this issue with a lot of my programs. I have no idea if this is a widely know issue or if I'm just particularly unluckily and/or unskilled when it comes to the GHC GC, but I thought it might be worth reporting as a bug. Here's a fairly simple program showing the issue: https://github.com/blitzcode/haskell-gol/tree/master/vector-glfwb (Note the 'GHC.Conc.getNumProcessors >>= setNumCapabilities', need to remove that for testing) On my quad core machine, this simple (non-parallel, some concurrency for draw & compute) Game-of-Life program runs as follows: +RTS -N1 = ~520G/s, CPU Load ~100% +RTS -N2 = ~505G/s, CPU Load ~135% +RTS -N3 = ~485G/s, CPU Load ~150% +RTS -N4 = ~485G/s, CPU Load ~160% Specifying -qg1 caps the CPU load increase at ~135% and it won't slow down below ~505G/s. The statistics from +RTS -s also suggest a decrease in GC time / increase in productivity through using -qg1. The program is a bit crummy, but it's the shortest example of this I got at hand. I've seen this in many different programs, serial GC just seems to be faster for a lot of workloads. I think it might at least be helpful to improve documentation a bit, suggesting some things to try for a GC speedup etc. Apologies if this is already a well-known issue or if I'm just doing something obviously dumb here that makes the GC perform poorly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8513> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8518: Build Extra Bodybuilding With Supplement
by GHC 10 Nov '13

10 Nov '13

#8518: Build Extra Bodybuilding With Supplement -------------------------------------------+------------------------------- Reporter: AnnDForbes | Owner: Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (FFI) | Version: 7.6.3 Keywords: Niwali Testobost | Operating System: Architecture: alpha | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- '''I said hey I make what you guys want to see like''' the two article I really did make that article for you guys because US so let me flip this around and show you so we'll start with preteen right here I'm sure must be as use this if you lightweights you probably know all about it to great supplement and I makes all three these things together for my workout drink and buying all these separately is so much cheaper than going out to you supplement store and buying a packaged per-workout those actually are pretty expensive and then moving on we've got some fish oil some calcium in a mufti-vitamin and of course I take away protein powder the brand really doesn’t matter this is salvation got pretty good record you guys can see right there I really like it but like I said it doesn’t matter what brand you use here's my thoughts about supplements I’ve never really talked about supplements but I think the whole supplement industry it's kind of a scam because most of the time when you want to go by a supplement all you see in the stores are like pro bodybuilders that have Avery impressive physique. '''It's true our way it's probably not true and a lot of''' the supplement companies can say whatever they would like on the bottle like gain because the supplement industry is it regulated there's actually a really good documentary that touch son this call bigger faster stronger thinker some combination of those three words and actually show how easy it is to make your own supplement and put some bogus claims on it and sell it’s kind of crazy and it really makes you think twice before going out and buying a supplement that probably doesn't work so the average person that buys one point was supplement a month for sixty dollars think how much that is over the course of one year it's a lot of money in here is my latest busy picture actually posted this the other day on Twitter and Integral you should follow me there if you don’t because overly be posting some more at a pretty happy. ''' I am a lot bigger than most people think because most the time''' in these articles you see mean my off day just standing in the kitchen you know not pumped up for anything they're going to try to get some workout out I found someone to fill which is great but that's pretty much it for this article my thoughts on supplements and which ones I take I hope you guys enjoy it and I hope you guys have a really get holiday season or whatever and I'll post this article and I think you guys will enjoy it little holiday spirit but I hope you guys have a good holiday like I said spend some time with your loved ones and be sure to check out this week's articles which is coming up on this outer screen. For more details http://www.niwalitest-o-boost.com/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8518> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 09 Nov '13

09 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 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 hvr): Replying to [comment:11 simonmar]: > We would have to move the existing `ExitCode` datatype into the `haskell2010` package, and do the corresponding refactorings. ...what's exactly involved here? Does this mean, that `haskell2010` (as well as `haskell98`) gets a //distinct// `System.Exit.ExitCode` type (but with the same name) as the one remaining in `base`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 09 Nov '13

09 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 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 hvr): Replying to [comment:19 andersk]: > Adding constructors to `ExitCode` seems to still be an option (comment:10, comment:11). I think that would make all the other proposed changes unnecessary. that change would involve modifications to `haskell2010`, `base`, `process` and maybe `unix` if I understand it right... :-/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 09 Nov '13

09 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 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 andersk): Adding constructors to `ExitCode` seems to still be an option (comment:10, comment:11). I think that would make all the other proposed changes unnecessary. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 09 Nov '13

09 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 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 hvr): Ok, in summary I see the following possibilities for the return value of the existing `waitForProcess` call on POSIX systems: 1. Use the reserved `ExitFailure 0` value to denote `WIFEXITED(s) == FALSE`; code should use the new API functions from comment:9 if it's interested in getting better exit-status information 2. Use the Perl/Python encoding convention for the argument of `ExitFailure`, i.e. {{{#!hs if coredump then 0x8000 else 0 .|. exit-status `shift` 8 .|. signum }}} causes impedance mismatch with the Haskell2010's `exitWith` 3. Use Bash-encoding for the argument of `ExitFailure` causes impedance mismatch with Haskell2010's `exitWith` I'm somewhat inclined to go with 1.; 2. would be tolerable if `exitWith` in base is adapted to interpret the exit code in the same way -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 09 Nov '13

09 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 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 andersk): Wikipedia is confused. If you go actually read the [http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html specification], you see > WEXITSTATUS(stat_val): … this macro evaluates to the low-order 8 bits of the status argument that the child process passed to _exit() or exit(), or the value the child process returned from main(). and also > The status values are retrieved by macros, rather than given as specific bit encodings as they are in most historical implementations (and thus expected by existing programs). This was necessary to eliminate a limitation on the number of signals an implementation can support that was inherent in the traditional encodings. Here’s the [https://sourceware.org/git/?p=glibc.git;a=blob;f=bits/waitstatus.h;hb=refs/… definition] from glibc: {{{ /* If WIFEXITED(STATUS), the low-order 8 bits of the status. */ #define __WEXITSTATUS(status) (((status) & 0xff00) >> 8) /* If WIFSIGNALED(STATUS), the terminating signal. */ #define __WTERMSIG(status) ((status) & 0x7f) }}} which is to say that bits 8-15 of the wait()/waitpid() status are bits 0-7 of the exit() status (the rest of the exit() status being thrown away), and bits 0-6 of the wait()/waitpid() status are the signal number. This agrees with the Perl/Python encoding (because, of course, that’s where the Perl/Python encoding came from). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0