Re: [GHC] #5210: Add primops for copying/cloning byte arrays
#5210: Add primops for copying/cloning byte arrays -+-- Reporter: tibbe |Owner: simonmar Type: feature request | Status: patch Priority: high |Milestone: 7.2.1 Component: Compiler | Version: 7.0.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by simonmar): * owner: tibbe = simonmar * priority: normal = high * milestone: = 7.2.1 Comment: Thanks, I'll review. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5210#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] #5210: Add primops for copying/cloning byte arrays
#5210: Add primops for copying/cloning byte arrays -+-- Reporter: tibbe |Owner: simonmar Type: feature request | Status: patch Priority: high |Milestone: 7.2.1 Component: Compiler | Version: 7.0.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by rl): It would probably make sense to have this for Addr#, too. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5210#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] #5173: Implement forward substitution of constants in the Cmm mini-inliner
#5173: Implement forward substitution of constants in the Cmm mini-inliner -+-- Reporter: tibbe |Owner: simonmar Type: feature request | Status: patch Priority: high |Milestone: 7.2.1 Component: Compiler | Version: 7.0.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by tibbe): * type: bug = feature request -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5173#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] #5212: waitForProcess: does not exist (No child processes)
#5212: waitForProcess: does not exist (No child processes)
---+
Reporter: chrisdone | Owner: chrisdone
Type: bug | Status: new
Priority: normal | Component: GHC API
Version: 6.12.3 |Keywords:
Testcase: | Blockedby:
Os: Linux |Blocking:
Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime
---+
I have this error when launching a program on our REHL prod machine.
{{{
waitForProcess: does not exist (No child processes)
}}}
This is called inside `readProcess`. I am unable to reproduce it on our
REHL dev machine, and my local Ubuntu machine. If I re-implement
`readProcess` with the same source but remove `waitForProcess` line, I do
get standard output. Launching the program is successful.
The problem stems from `waitForProcess` expecting a process and somehow
there isn't one. I didn't think this would be a problem, because
`waitForProcess` itself doesn't throw such an exception, and it *does*
handle the process having ended (of course), which is trivial to confirm
locally:
{{{
λ (inh,outh,_,pid) - createProcess (proc date [])
Tue May 24 11:19:59 CEST 2011
λ waitForProcess pid
ExitSuccess
λ
}}}
So perhaps it's in `withProcessHandle`, which I don't have access to in
the Haddock docs. I don't really know what would cause this error. Ideas?
We're using GHC 6.12.3 (I know, not recent). I'd provide a test-case but I
can't even reproduce it on my own machine. I don't have direct shell
access to the prod machine. The test-case would essentially be use
readProcess, anyway.
I can assign this to me and I'll see if the problem persists when we
upgrade to GHC7. FWIW if you want to reproduce the exact case I tried,
here it is:
{{{
readProcess pdfinfo [--help]
}}}
{{{
$ pdfinfo -v
pdfinfo version 3.00
Copyright 1996-2004 Glyph Cog, LLC
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5212
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] #4163: Make cross-compilation work
#4163: Make cross-compilation work -+-- Reporter: simonmar |Owner: Type: task | Status: patch Priority: high |Milestone: 7.4.1 Component: Build System | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Difficult (2-5 days) Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by simonmar): * owner: simonmar = Comment: unassigning myself, I don't think I own this ticket -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4163#comment:26 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] #5111: linux-powerpc : segfault in stage2 compiler
#5111: linux-powerpc : segfault in stage2 compiler -+-- Reporter: erikd |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Linux | Blocking: Architecture: powerpc | Failure: Installing GHC failed -+-- Comment(by erikd): Since Simon suggests this is a linker problem, I'm revisiting the file rts/Linker.c. The Macho-O powerpc linker messes with the misalignment field of the `ObjectCode` struct in `rts/LinkerInternals.h`. I understand the reasoning for this with `Mach-O` object files and I'm trying to figure out if something similar is needed for `ELF` files on linux-powerpc. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5111#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] #5210: Add primops for copying/cloning byte arrays
#5210: Add primops for copying/cloning byte arrays -+-- Reporter: tibbe |Owner: simonmar Type: feature request | Status: patch Priority: high |Milestone: 7.2.1 Component: Compiler | Version: 7.0.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by tibbe): Do we have a way to convert an Addr# to a pointer in Haskell code? If so, couldn't one just call memcpy directly on the pointer? The reason I'm adding these primops is that pointer arithmetic is not possible on `ByteArray#`s, as any interior pointer you grab could be invalid by the time you call `memcpy`, as the GC might move the array. Since `Addr#` point outside the heap it should be safe to use pointer arithmetic on them. In any case, please open a separate ticket. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5210#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] #5210: Add primops for copying/cloning byte arrays
#5210: Add primops for copying/cloning byte arrays -+-- Reporter: tibbe |Owner: simonmar Type: feature request | Status: patch Priority: high |Milestone: 7.2.1 Component: Compiler | Version: 7.0.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by rl): Addr# is what Ptr and friends are implemented on top of. The operations would only be useful for unrolling, not for the pointer arithmetic. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5210#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] #5111: linux-powerpc : segfault in stage2 compiler
#5111: linux-powerpc : segfault in stage2 compiler
-+--
Reporter: erikd |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 7.1
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Linux | Blocking:
Architecture: powerpc | Failure: Installing GHC failed
-+--
Comment(by erikd):
The
[http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html
Mach-O documentation] suggests that the alignment is calculated by:
{{{
misalignment = (header.sizeofcmds + sizeof(header)) 0xF;
return misalignment ? (16 - misalignment) : 0;
}}}
is all about finding the start of the actual code within the object file.
My reading of the ELF documentation suggests that the ELF version should
look like this:
{{{
misalignment = header.e_ehsize 0xF;
return misalignment ? (16 - misalignment) : 0;}}}
}}}
but that still doesn't work. For all the ghc generated object files I've
seen the .text section immediately follows the `ELF` header whose size if
specified by e_ehsize.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5111#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
[GHC] #5213: Makefile tests don't know about config.compiler_always_flags
#5213: Makefile tests don't know about config.compiler_always_flags
-+--
Reporter: igloo |Owner: igloo
Type: bug | Status: new
Priority: normal|Milestone: 7.4.1
Component: Test Suite| Version: 7.0.3
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
the flags that we pass to GHC for most tests are set in config/ghc:
{{{
config.compiler_always_flags = ['-fforce-recomp', '-dcore-lint', '-dcmm-
lint',
'-dno-debug-output', '-no-user-package-
conf', '-rtsopts']
}}}
These ought to be somewhere that we can get at them in a Makefile too.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5213
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] #4965: 60% performance regression in continuation-heavy code between 6.12 and 7
#4965: 60% performance regression in continuation-heavy code between 6.12 and 7 --+- Reporter: bos | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 7.2.1 Component: Compiler |Version: 7.0.1 Resolution: fixed| Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --+- Changes (by simonmar): * status: new = closed * resolution: = fixed Comment: Not feasible to add a test, I think. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4965#comment:15 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] #5026: +RTS -G1 is broken
#5026: +RTS -G1 is broken -+-- Reporter: igloo |Owner: simonmar Type: bug | Status: new Priority: high |Milestone: 7.2.1 Component: Runtime System| Version: 7.0.2 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by simonmar): * owner: igloo = simonmar Comment: I'm fixing this -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5026#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] #5210: Add primops for copying/cloning byte arrays
#5210: Add primops for copying/cloning byte arrays -+-- Reporter: tibbe |Owner: simonmar Type: feature request | Status: patch Priority: high |Milestone: 7.2.1 Component: Compiler | Version: 7.0.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by tibbe): Replying to [comment:5 rl]: Addr# is what Ptr and friends are implemented on top of. The operations would only be useful for unrolling, not for the pointer arithmetic. Fair enough. Once we have the actual unrolling going in the backends (LLVM will be first) we can look into it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5210#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] #4888: Document behaviour of throwTo to your own ThreadId
#4888: Document behaviour of throwTo to your own ThreadId +--- Reporter: batterseapower | Owner: simonmar Type: bug| Status: closed Priority: normal | Milestone: 7.4.1 Component: Documentation |Version: 7.0.1 Resolution: fixed | Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Documentation bug | +--- Changes (by simonmar): * status: new = closed * resolution: = fixed Comment: Fixed: changeset:d8c8a1a857709334949d680d6afa274b7c6c7809 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4888#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] #5026: +RTS -G1 is broken
#5026: +RTS -G1 is broken -+-- Reporter: igloo | Owner: simonmar Type: bug | Status: closed Priority: high| Milestone: 7.2.1 Component: Runtime System |Version: 7.0.2 Resolution: fixed | Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown| -+-- Changes (by simonmar): * status: new = closed * resolution: = fixed Comment: Fixed: changeset:c7e3cba25cbb0c50e27ca1df4ef71cf3556a492c -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5026#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] #5086: internal error: update_fwd: unknown/strange object -1206004376
#5086: internal error: update_fwd: unknown/strange object -1206004376 ---+ Reporter: danw|Owner: Type: bug | Status: infoneeded Priority: normal |Milestone: 7.2.1 Component: Runtime System | Version: 6.12.3 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64) | Failure: Runtime crash ---+ Comment(by j.waldmann): I have that same behaviour for 7.0.3 internal error: update_fwd: unknown/strange object 8 (GHC version 7.0.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted when I run the attached program on 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 (should take 60 seconds, eats up all the heap, then crashes reliable) the program does nothing special - just allocate Cons cells. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5086#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] #5086: internal error: update_fwd: unknown/strange object -1206004376
#5086: internal error: update_fwd: unknown/strange object -1206004376
---+
Reporter: danw|Owner:
Type: bug | Status: infoneeded
Priority: normal |Milestone: 7.2.1
Component: Runtime System | Version: 6.12.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86_64 (amd64) | Failure: Runtime crash
---+
Comment(by j.waldmann):
here's the commands I use:
{{{
ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.3
ghc --make -threaded -rtsopts -O2 -fforce-recomp Space.hs
time ./Space +RTS -N1 -M8G(1,[1])
(2,[2])
(3,[6])
(4,[24])
(5,[120])
(6,[720])
(7,[5040])
(8,[40320])
(9,[362880])
(10,[3628800])
Space: internal error: update_fwd: unknown/strange object 8
(GHC version 7.0.3 for x86_64_unknown_linux)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
Aborted
real0m49.840s
user0m46.280s
sys 0m3.500s
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5086#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] #5086: internal error: update_fwd: unknown/strange object -1206004376
#5086: internal error: update_fwd: unknown/strange object -1206004376 ---+ Reporter: danw|Owner: Type: bug | Status: new Priority: normal |Milestone: 7.2.1 Component: Runtime System | Version: 6.12.3 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64) | Failure: Runtime crash ---+ Changes (by simonmar): * status: infoneeded = new -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5086#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] #5086: internal error: update_fwd: unknown/strange object -1206004376
#5086: internal error: update_fwd: unknown/strange object -1206004376 ---+ Reporter: danw|Owner: simonmar Type: bug | Status: new Priority: high|Milestone: 7.2.1 Component: Runtime System | Version: 6.12.3 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64) | Failure: Runtime crash ---+ Changes (by simonmar): * owner: = simonmar * priority: normal = high -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5086#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] #4978: Continuation passing style loop doesn't compile into a loop
#4978: Continuation passing style loop doesn't compile into a loop -+-- Reporter: tibbe |Owner: Type: bug | Status: new Priority: normal|Milestone: 7.4.1 Component: Compiler | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by tibbe): The current HEAD now generates good core for `Repro3.hs`, thanks to Simon Marlow. However, I've attached a more difficult (but real life) test case that still causes a closure to be allocated each time around the loop. The main difference from `Repro3.hs` is that we now write four bytes at the time, increasing the size of the loop body a little bit. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4978#comment:20 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] #5214: SIGSEGV in yieldCapability ()
#5214: SIGSEGV in yieldCapability ()
---+
Reporter: j.waldmann | Owner:
Type: bug | Status: new
Priority: normal | Component: Runtime System
Version: 7.0.3 |Keywords:
Testcase: | Blockedby:
Os: Linux |Blocking:
Architecture: x86_64 (amd64) | Failure: Runtime crash
---+
Comment(by j.waldmann):
Here is the end of an strace of a run that leads to a crash:
{{{
...
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0x19ee4fc, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19ee4f8, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x1a1826c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x1a18268, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19b381c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19b3818, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edb2c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19edb28, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edd4c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19edd48, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edd78, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1932a88, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x19ee35c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19ee358, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19ee388, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1932e08, FUTEX_WAKE_PRIVATE, 1) = 1
rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
sched_yield() = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0x19ee4fc, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19ee4f8, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x1a1826c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x1a18268, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19b381c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19b3818, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edb2c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19edb28, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edd4c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19edd48, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edd78, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1932a88, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x19ee35c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19ee358, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19ee388, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1932e08, FUTEX_WAKE_PRIVATE, 1) = 1
rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
sched_yield() = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0x19ee4fc, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19ee4f8, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x1a1826c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x1a18268, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19b381c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19b3818, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edb2c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19edb28, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edd4c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19edd48, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edd78, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1932a88, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x19ee35c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19ee358, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19ee388, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1932e08, FUTEX_WAKE_PRIVATE, 1) = 1
rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
sched_yield() = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0x19ee4fc, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19ee4f8, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x1a1826c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x1a18268, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19b381c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19b3818, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edb2c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19edb28, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edd4c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19edd48, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edd78, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1932a88, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x19ee35c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19ee358, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19ee388, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1932e08, FUTEX_WAKE_PRIVATE, 1) = 1
rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
sched_yield() = 0
sched_yield()
Re: [GHC] #4393: GHCi says: ghc: internal error: evacuate: strange closure type 63587
#4393: GHCi says: ghc: internal error: evacuate: strange closure type 63587 -+-- Reporter: chrisdone | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: GHCi|Version: 6.12.3 Resolution: worksforme | Keywords: Testcase: | Blockedby: Difficulty: | Os: Linux Blocking: | Architecture: x86 Failure: GHCi crash | -+-- Changes (by simonmar): * status: infoneeded = closed * resolution: = worksforme Comment: no further info forthcoming, so closing. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4393#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] #5215: process library does not build with GHC 7.0.x
#5215: process library does not build with GHC 7.0.x -+-- Reporter: Favonia | Owner: Favonia Type: bug | Status: new Priority: normal| Component: libraries/process Version: 7.0.3 |Keywords: interruptible waitForProcess Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: Building GHC failed -+-- The process library in the trunk does not build with GHC 7.0.x. The reason is that GHC 7.0.x does not seem to support the interruptible FFI calls, but the macro asserts that GHC 7 supports it. People on #ghc (thanks to thoughtpolice) have confirmed that GHC 7.1.x supports it. I hereby propose a patch to bump the version check from 700 to 710. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5215 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] #3268: implement the Cabal ${pkgroot} spec extension
#3268: implement the Cabal ${pkgroot} spec extension
-+--
Reporter: duncan|Owner:
Type: feature request | Status: new
Priority: normal|Milestone: 7.2.1
Component: Package system| Version: 6.10.2
Keywords:| Testcase:
Blockedby:| Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by duncan):
Replying to [comment:2 duncan]:
* for `ghc-pkg dump`, we prefix each batch of packages with the
`pkgroot` value
(choosing some suitable syntax)
Yes. Some suitable syntax we've not yet chosen :-)
I've decided that the simplest thing to do is to just have it as an extra
field:
{{{
pkgroot: /the/path/that/is/the/pkgroot
}}}
So this field may be in the output, but never in the input (if it is it's
ignored like all other unknown fields).
There are two cases:
* `--expand-vars`: in this case `ghc-pkg dump`/`describe` will expand the
`${pkgroot}` and `${pkgrooturl}` vars and will not generate the `pkgroot`
field.
* `--no-expand-vars`: in this case `ghc-pkg dump`/`describe` will not
expand the `${pkgroot}` var, so it will appear literally in the output and
the `pkgroot` field will be generated so that tools know what value to use
for the `${pkgroot}`.
The defaults are:
* `ghc-pkg dump` uses `--no-expand-vars` by default, but this can be
reversed with `--expand-vars`
* `ghc-pkg describe` uses `--expand-vars` by default, but this can be
reversed with `--no-expand-vars`
(Alternatively could be more explicit and say `-(no-)expand-pkgroot`.)
Sound sane?
None of this applies to hugs/nhc style file databases because there tools
always know exactly what the pkgroot is, as it's just the dir containing
the file they read. Because `ghc-pkg` has a looser connection between the
package info and the locations they come from then we need this (or a
similar) extra mechanism.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3268#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] #5177: Segfault in reportCCSProfiling
#5177: Segfault in reportCCSProfiling ---+ Reporter: dankna |Owner: Type: bug | Status: new Priority: high|Milestone: 7.2.1 Component: Profiling | Version: 7.1 Keywords: | Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: Runtime crash ---+ Changes (by dankna): * status: infoneeded = new Comment: Okay, so I did this. The stack trace wasn't any more useful (everything outside the reportCCSProfiling frame was my Objective-C main program or Apple's Cocoa code), but source-level debugging worked, so I was able to track down the problem. Turns out it was a misusage on my part, rather than a GHC bug, but it should be documented so nobody else has this confusion. The issue was that the memory I had passed to hs_init() was not my real argc and argv, but rather a massaged version that I had dynamically allocated, and was freeing immediately after hs_init() returns. Since the code that outputs the profiling data assumes that memory is statically allocated and therefore still valid, I was getting intermittent crashes. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5177#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] #4385: Type-level natural numbers
#4385: Type-level natural numbers +--- Reporter: diatchki |Owner: diatchki Type: feature request | Status: new Priority: normal |Milestone: 7.4.1 Component: Compiler (Type checker) | Version: Keywords: | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown +--- Changes (by Favonia): * cc: favonia@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4385#comment:37 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] #5216: Haskell Platform 2011.2.0.1 Setup
#5216: Haskell Platform 2011.2.0.1 Setup -+-- Reporter: guest | Owner: Type: bug | Status: new Priority: normal| Component: Package system Version: 7.0.3 |Keywords: setup windows 7 Testcase:| Blockedby: Os: Windows |Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Could not write updated PATH to HKLM This message was given three times when I installed Haskell Platform 2011.2.0.1 on my brand new Windows 7 Enterprise (with Service Pack 1) computer. (btw, a version I downloaded three months ago did exactly the same) After inserting the path by hand in the environment variables, ghc was found from the command prompt. The fact that this message was given three times, and I just resolved one path, suggests that I am missing two other paths. Could you let me know which ones? Thanks, Stef Joosten stef.joos...@ou.nl -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5216 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
