July 2015 - ghc-tickets

Re: [GHC] #4: -fext-core -fno-core behaves funny
by GHC 07 Jul '15

07 Jul '15

#4: -fext-core -fno-core behaves funny ---------------------+-------------------- Reporter: josefs | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: None Resolution: Fixed | Keywords: ---------------------+-------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"5857e0afb5823987e84e6d3dd8d0b269b7546166/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5857e0afb5823987e84e6d3dd8d0b269b7546166" fix EBADF unqueueing in select backend (Trac #10590) Alexander found a interesting case: 1. We have a queue of two waiters in a blocked_queue 2. first file descriptor changes state to RUNNABLE, second changes to INVALID 3. awaitEvent function dequeued RUNNABLE thread to a run queue and attempted to dequeue INVALID descriptor to a run queue. Unqueueing INVALID fails thusly: #3 0x000000000045cf1c in barf (s=0x4c1cb0 "removeThreadFromDeQueue: not found") at rts/RtsMessages.c:42 #4 0x000000000046848b in removeThreadFromDeQueue (...) at rts/Threads.c:249 #5 0x000000000049a120 in removeFromQueues (...) at rts/RaiseAsync.c:719 #6 0x0000000000499502 in throwToSingleThreaded__ (...) at rts/RaiseAsync.c:67 #7 0x0000000000499555 in throwToSingleThreaded (..) at rts/RaiseAsync.c:75 #8 0x000000000047c27d in awaitEvent (wait=rtsFalse) at rts/posix/Select.c:415 The problem here is a throwToSingleThreaded function that tries to unqueue a TSO from blocked_queue, but awaitEvent function leaves blocked_queue in a inconsistent state while traverses over blocked_queue: case RTS_FD_IS_READY: IF_DEBUG(scheduler, debugBelch("Waking up blocked thread %lu\n", (unsigned long)tso->id)); tso->why_blocked = NotBlocked; tso->_link = END_TSO_QUEUE; // Here we break the queue head pushOnRunQueue(&MainCapability,tso); break; Signed-off-by: Sergei Trofimovich <siarheit(a)google.com> Test Plan: tested on a sample from T10590 Reviewers: austin, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: qnikst, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1024 GHC Trac Issues: #10590, #4934 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6: Debugging info confuses runtime linker
by GHC 07 Jul '15

07 Jul '15

#6: Debugging info confuses runtime linker -----------------------------+--------------------- Reporter: simonmar | Owner: sewardj Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 5.02 Resolution: Fixed | Keywords: -----------------------------+--------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"5857e0afb5823987e84e6d3dd8d0b269b7546166/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5857e0afb5823987e84e6d3dd8d0b269b7546166" fix EBADF unqueueing in select backend (Trac #10590) Alexander found a interesting case: 1. We have a queue of two waiters in a blocked_queue 2. first file descriptor changes state to RUNNABLE, second changes to INVALID 3. awaitEvent function dequeued RUNNABLE thread to a run queue and attempted to dequeue INVALID descriptor to a run queue. Unqueueing INVALID fails thusly: #3 0x000000000045cf1c in barf (s=0x4c1cb0 "removeThreadFromDeQueue: not found") at rts/RtsMessages.c:42 #4 0x000000000046848b in removeThreadFromDeQueue (...) at rts/Threads.c:249 #5 0x000000000049a120 in removeFromQueues (...) at rts/RaiseAsync.c:719 #6 0x0000000000499502 in throwToSingleThreaded__ (...) at rts/RaiseAsync.c:67 #7 0x0000000000499555 in throwToSingleThreaded (..) at rts/RaiseAsync.c:75 #8 0x000000000047c27d in awaitEvent (wait=rtsFalse) at rts/posix/Select.c:415 The problem here is a throwToSingleThreaded function that tries to unqueue a TSO from blocked_queue, but awaitEvent function leaves blocked_queue in a inconsistent state while traverses over blocked_queue: case RTS_FD_IS_READY: IF_DEBUG(scheduler, debugBelch("Waking up blocked thread %lu\n", (unsigned long)tso->id)); tso->why_blocked = NotBlocked; tso->_link = END_TSO_QUEUE; // Here we break the queue head pushOnRunQueue(&MainCapability,tso); break; Signed-off-by: Sergei Trofimovich <siarheit(a)google.com> Test Plan: tested on a sample from T10590 Reviewers: austin, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: qnikst, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1024 GHC Trac Issues: #10590, #4934 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5: fails if library has main()
by GHC 07 Jul '15

07 Jul '15

#5: fails if library has main() -----------------------+---------------------- Reporter: cwitty | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: 5.02 Resolution: Wont Fix | Keywords: -----------------------+---------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"5857e0afb5823987e84e6d3dd8d0b269b7546166/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5857e0afb5823987e84e6d3dd8d0b269b7546166" fix EBADF unqueueing in select backend (Trac #10590) Alexander found a interesting case: 1. We have a queue of two waiters in a blocked_queue 2. first file descriptor changes state to RUNNABLE, second changes to INVALID 3. awaitEvent function dequeued RUNNABLE thread to a run queue and attempted to dequeue INVALID descriptor to a run queue. Unqueueing INVALID fails thusly: #3 0x000000000045cf1c in barf (s=0x4c1cb0 "removeThreadFromDeQueue: not found") at rts/RtsMessages.c:42 #4 0x000000000046848b in removeThreadFromDeQueue (...) at rts/Threads.c:249 #5 0x000000000049a120 in removeFromQueues (...) at rts/RaiseAsync.c:719 #6 0x0000000000499502 in throwToSingleThreaded__ (...) at rts/RaiseAsync.c:67 #7 0x0000000000499555 in throwToSingleThreaded (..) at rts/RaiseAsync.c:75 #8 0x000000000047c27d in awaitEvent (wait=rtsFalse) at rts/posix/Select.c:415 The problem here is a throwToSingleThreaded function that tries to unqueue a TSO from blocked_queue, but awaitEvent function leaves blocked_queue in a inconsistent state while traverses over blocked_queue: case RTS_FD_IS_READY: IF_DEBUG(scheduler, debugBelch("Waking up blocked thread %lu\n", (unsigned long)tso->id)); tso->why_blocked = NotBlocked; tso->_link = END_TSO_QUEUE; // Here we break the queue head pushOnRunQueue(&MainCapability,tso); break; Signed-off-by: Sergei Trofimovich <siarheit(a)google.com> Test Plan: tested on a sample from T10590 Reviewers: austin, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: qnikst, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1024 GHC Trac Issues: #10590, #4934 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8: Regex failure
by GHC 07 Jul '15

07 Jul '15

#8: Regex failure --------------------------+---------------------- Reporter: xoltar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: hslibs/text | Version: 5.02 Resolution: Fixed | Keywords: --------------------------+---------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"5857e0afb5823987e84e6d3dd8d0b269b7546166/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5857e0afb5823987e84e6d3dd8d0b269b7546166" fix EBADF unqueueing in select backend (Trac #10590) Alexander found a interesting case: 1. We have a queue of two waiters in a blocked_queue 2. first file descriptor changes state to RUNNABLE, second changes to INVALID 3. awaitEvent function dequeued RUNNABLE thread to a run queue and attempted to dequeue INVALID descriptor to a run queue. Unqueueing INVALID fails thusly: #3 0x000000000045cf1c in barf (s=0x4c1cb0 "removeThreadFromDeQueue: not found") at rts/RtsMessages.c:42 #4 0x000000000046848b in removeThreadFromDeQueue (...) at rts/Threads.c:249 #5 0x000000000049a120 in removeFromQueues (...) at rts/RaiseAsync.c:719 #6 0x0000000000499502 in throwToSingleThreaded__ (...) at rts/RaiseAsync.c:67 #7 0x0000000000499555 in throwToSingleThreaded (..) at rts/RaiseAsync.c:75 #8 0x000000000047c27d in awaitEvent (wait=rtsFalse) at rts/posix/Select.c:415 The problem here is a throwToSingleThreaded function that tries to unqueue a TSO from blocked_queue, but awaitEvent function leaves blocked_queue in a inconsistent state while traverses over blocked_queue: case RTS_FD_IS_READY: IF_DEBUG(scheduler, debugBelch("Waking up blocked thread %lu\n", (unsigned long)tso->id)); tso->why_blocked = NotBlocked; tso->_link = END_TSO_QUEUE; // Here we break the queue head pushOnRunQueue(&MainCapability,tso); break; Signed-off-by: Sergei Trofimovich <siarheit(a)google.com> Test Plan: tested on a sample from T10590 Reviewers: austin, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: qnikst, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1024 GHC Trac Issues: #10590, #4934 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7: dodgy case of unboxed tuple type
by GHC 07 Jul '15

07 Jul '15

#7: dodgy case of unboxed tuple type -----------------------+-------------------- Reporter: mtehver | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.02 Resolution: Fixed | Keywords: -----------------------+-------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"5857e0afb5823987e84e6d3dd8d0b269b7546166/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5857e0afb5823987e84e6d3dd8d0b269b7546166" fix EBADF unqueueing in select backend (Trac #10590) Alexander found a interesting case: 1. We have a queue of two waiters in a blocked_queue 2. first file descriptor changes state to RUNNABLE, second changes to INVALID 3. awaitEvent function dequeued RUNNABLE thread to a run queue and attempted to dequeue INVALID descriptor to a run queue. Unqueueing INVALID fails thusly: #3 0x000000000045cf1c in barf (s=0x4c1cb0 "removeThreadFromDeQueue: not found") at rts/RtsMessages.c:42 #4 0x000000000046848b in removeThreadFromDeQueue (...) at rts/Threads.c:249 #5 0x000000000049a120 in removeFromQueues (...) at rts/RaiseAsync.c:719 #6 0x0000000000499502 in throwToSingleThreaded__ (...) at rts/RaiseAsync.c:67 #7 0x0000000000499555 in throwToSingleThreaded (..) at rts/RaiseAsync.c:75 #8 0x000000000047c27d in awaitEvent (wait=rtsFalse) at rts/posix/Select.c:415 The problem here is a throwToSingleThreaded function that tries to unqueue a TSO from blocked_queue, but awaitEvent function leaves blocked_queue in a inconsistent state while traverses over blocked_queue: case RTS_FD_IS_READY: IF_DEBUG(scheduler, debugBelch("Waking up blocked thread %lu\n", (unsigned long)tso->id)); tso->why_blocked = NotBlocked; tso->_link = END_TSO_QUEUE; // Here we break the queue head pushOnRunQueue(&MainCapability,tso); break; Signed-off-by: Sergei Trofimovich <siarheit(a)google.com> Test Plan: tested on a sample from T10590 Reviewers: austin, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: qnikst, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1024 GHC Trac Issues: #10590, #4934 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS
by GHC 07 Jul '15

07 Jul '15

#4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: ------------------------------------------------+-------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"5857e0afb5823987e84e6d3dd8d0b269b7546166/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5857e0afb5823987e84e6d3dd8d0b269b7546166" fix EBADF unqueueing in select backend (Trac #10590) Alexander found a interesting case: 1. We have a queue of two waiters in a blocked_queue 2. first file descriptor changes state to RUNNABLE, second changes to INVALID 3. awaitEvent function dequeued RUNNABLE thread to a run queue and attempted to dequeue INVALID descriptor to a run queue. Unqueueing INVALID fails thusly: #3 0x000000000045cf1c in barf (s=0x4c1cb0 "removeThreadFromDeQueue: not found") at rts/RtsMessages.c:42 #4 0x000000000046848b in removeThreadFromDeQueue (...) at rts/Threads.c:249 #5 0x000000000049a120 in removeFromQueues (...) at rts/RaiseAsync.c:719 #6 0x0000000000499502 in throwToSingleThreaded__ (...) at rts/RaiseAsync.c:67 #7 0x0000000000499555 in throwToSingleThreaded (..) at rts/RaiseAsync.c:75 #8 0x000000000047c27d in awaitEvent (wait=rtsFalse) at rts/posix/Select.c:415 The problem here is a throwToSingleThreaded function that tries to unqueue a TSO from blocked_queue, but awaitEvent function leaves blocked_queue in a inconsistent state while traverses over blocked_queue: case RTS_FD_IS_READY: IF_DEBUG(scheduler, debugBelch("Waking up blocked thread %lu\n", (unsigned long)tso->id)); tso->why_blocked = NotBlocked; tso->_link = END_TSO_QUEUE; // Here we break the queue head pushOnRunQueue(&MainCapability,tso); break; Signed-off-by: Sergei Trofimovich <siarheit(a)google.com> Test Plan: tested on a sample from T10590 Reviewers: austin, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: qnikst, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1024 GHC Trac Issues: #10590, #4934 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4934#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10205: On Windows ghc-pkg always reports cache out of date
by GHC 07 Jul '15

07 Jul '15

#10205: On Windows ghc-pkg always reports cache out of date -------------------------------------+------------------------------------- Reporter: hgolden | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Incorrect result Test Case: | at runtime Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- When I ran {{{ghc-pkg list}}} on Windows, it reported that the global and user caches were out of date. As instructed, I recached both caches. Despite this, I continued to get the same error message. It appears that the timestamp on the package.conf.d directory is always a few milliseconds later than the timestamp of the package cache, even after recaching, as shown by the log excerpt below. Original error: {{{ C:\Users\hgolden\AppData\Roaming>ghc-pkg check WARNING: cache is out of date: C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. WARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. [snip...] }}} Checking timestamps: {{{ C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 list Timestamp 2015-03-27 21:18:29.5247984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\pa ckage.cache Timestamp 2015-03-27 21:18:29.5277984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d (N EWER than cache) WARNING: cache is out of date: C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. [snip...] Timestamp 2015-03-27 21:15:48.6285984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache Timestamp 2015-03-27 21:15:48.6835984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d (NEWER than c ache) WARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. [snip...] }}} Recaching as instructed: {{{ C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 recache --user [snip...] modifying: Just "C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d" flag db stack: ["C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d"] writing cache C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 recache --global [snip...] modifying: Just "C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d" flag db stack: ["C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d"] writing cache C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache }}} Looking at timestamps after recaching: {{{ C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 list Timestamp 2015-03-27 21:21:50.3341984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\pa ckage.cache Timestamp 2015-03-27 21:21:50.3371984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d (N EWER than cache) WARNING: cache is out of date: C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. [snip...] Timestamp 2015-03-27 21:23:05.4329984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache Timestamp 2015-03-27 21:23:05.4359984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d (NEWER than c ache) WARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. C:\Users\hgolden\AppData\Roaming> }}} Timestamps have changed, but each directory's timestamp is still a few milliseconds after each cache file's timestamp. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10205> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10587: Suspending and unsuspending ghci kills and spawns threads
by GHC 07 Jul '15

07 Jul '15

#10587: Suspending and unsuspending ghci kills and spawns threads -----------------------------------------+--------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- When you run: {{{ ghci -j8 # in a different terminal: pidstat -t -p $(pidof ghc) | grep ghc_worker kill -SIGSTOP $(pidof ghc); kill -SIGCONT $(pidof ghc) # SIGCONT doesn't really resume it, you have to run fg in the terminal where it runs pidstat -t -p $(pidof ghc) | grep ghc_worker kill -SIGSTOP $(pidof ghc); kill -SIGCONT $(pidof ghc) pidstat -t -p $(pidof ghc) | grep ghc_worker kill -SIGSTOP $(pidof ghc); kill -SIGCONT $(pidof ghc) pidstat -t -p $(pidof ghc) | grep ghc_worker }}} You get: {{{ $ pidstat -t -p $(pidof ghc) | grep ghc_worker 06:40:55 AM - 2848953 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:40:55 AM - 2848954 0.00 0.00 0.00 0.00 31 |__ghc_worker 06:40:55 AM - 2848955 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:40:55 AM - 2848957 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:40:55 AM - 2848958 0.00 0.00 0.00 0.00 22 |__ghc_worker 06:40:55 AM - 2848959 0.00 0.00 0.00 0.00 37 |__ghc_worker 06:40:55 AM - 2848960 0.00 0.00 0.00 0.00 3 |__ghc_worker 06:40:55 AM - 2848961 0.00 0.00 0.00 0.00 2 |__ghc_worker 06:40:55 AM - 2848962 0.00 0.00 0.00 0.00 36 |__ghc_worker 06:40:55 AM - 2848963 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:40:55 AM - 2848964 0.00 0.00 0.00 0.00 31 |__ghc_worker 06:40:55 AM - 2848965 0.00 0.00 0.00 0.00 11 |__ghc_worker 06:40:55 AM - 2848966 0.00 0.00 0.00 0.00 24 |__ghc_worker 06:40:55 AM - 2848967 0.00 0.00 0.00 0.00 38 |__ghc_worker 06:40:55 AM - 2848968 0.00 0.00 0.00 0.00 23 |__ghc_worker 06:40:55 AM - 2848969 0.00 0.00 0.00 0.00 22 |__ghc_worker 06:40:55 AM - 2848970 0.00 0.00 0.00 0.00 31 |__ghc_worker }}} {{{ $ pidstat -t -p $(pidof ghc) | grep ghc_worker 06:41:37 AM - 2848953 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:41:37 AM - 2848954 0.00 0.00 0.00 0.00 31 |__ghc_worker 06:41:37 AM - 2848955 0.00 0.00 0.00 0.00 3 |__ghc_worker 06:41:37 AM - 2848957 0.00 0.00 0.00 0.00 3 |__ghc_worker 06:41:37 AM - 2848958 0.00 0.00 0.00 0.00 22 |__ghc_worker 06:41:37 AM - 2848959 0.00 0.00 0.00 0.00 37 |__ghc_worker 06:41:37 AM - 2848960 0.00 0.00 0.00 0.00 5 |__ghc_worker 06:41:37 AM - 2848961 0.00 0.00 0.00 0.00 5 |__ghc_worker 06:41:37 AM - 2848962 0.00 0.00 0.00 0.00 36 |__ghc_worker 06:41:37 AM - 2848963 0.00 0.00 0.00 0.00 7 |__ghc_worker 06:41:37 AM - 2848964 0.00 0.00 0.00 0.00 12 |__ghc_worker 06:41:37 AM - 2848965 0.00 0.00 0.00 0.00 11 |__ghc_worker 06:41:37 AM - 2848966 0.00 0.00 0.00 0.00 24 |__ghc_worker 06:41:37 AM - 2848967 0.00 0.00 0.00 0.00 38 |__ghc_worker 06:41:37 AM - 2848968 0.00 0.00 0.00 0.00 23 |__ghc_worker 06:41:37 AM - 2848969 0.00 0.00 0.00 0.00 8 |__ghc_worker 06:41:37 AM - 2848970 0.00 0.00 0.00 0.00 14 |__ghc_worker 06:41:37 AM - 2850193 0.00 0.00 0.00 0.00 32 |__ghc_worker 06:41:37 AM - 2850194 0.00 0.00 0.00 0.00 33 |__ghc_worker 06:41:37 AM - 2850196 0.00 0.00 0.00 0.00 34 |__ghc_worker 06:41:37 AM - 2850197 0.00 0.00 0.00 0.00 35 |__ghc_worker 06:41:37 AM - 2850198 0.00 0.00 0.00 0.00 10 |__ghc_worker 06:41:37 AM - 2850199 0.00 0.00 0.00 0.00 17 |__ghc_worker 06:41:37 AM - 2850294 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:41:37 AM - 2850295 0.00 0.00 0.00 0.00 31 |__ghc_worker }}} {{{ $ pidstat -t -p $(pidof ghc) | grep ghc_worker 06:42:43 AM - 2848953 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:42:43 AM - 2848954 0.00 0.00 0.00 0.00 31 |__ghc_worker 06:42:43 AM - 2848955 0.00 0.00 0.00 0.00 3 |__ghc_worker 06:42:43 AM - 2848957 0.00 0.00 0.00 0.00 7 |__ghc_worker 06:42:43 AM - 2848958 0.00 0.00 0.00 0.00 22 |__ghc_worker 06:42:43 AM - 2848959 0.00 0.00 0.00 0.00 37 |__ghc_worker 06:42:43 AM - 2848960 0.00 0.00 0.00 0.00 9 |__ghc_worker 06:42:43 AM - 2848961 0.00 0.00 0.00 0.00 0 |__ghc_worker 06:42:43 AM - 2848962 0.00 0.00 0.00 0.00 36 |__ghc_worker 06:42:43 AM - 2848963 0.00 0.00 0.00 0.00 4 |__ghc_worker 06:42:43 AM - 2848964 0.00 0.00 0.00 0.00 12 |__ghc_worker 06:42:43 AM - 2848965 0.00 0.00 0.00 0.00 11 |__ghc_worker 06:42:43 AM - 2848966 0.00 0.00 0.00 0.00 24 |__ghc_worker 06:42:43 AM - 2848967 0.00 0.00 0.00 0.00 38 |__ghc_worker 06:42:43 AM - 2848968 0.00 0.00 0.00 0.00 23 |__ghc_worker 06:42:43 AM - 2848969 0.00 0.00 0.00 0.00 29 |__ghc_worker 06:42:43 AM - 2848970 0.00 0.00 0.00 0.00 14 |__ghc_worker 06:42:43 AM - 2850193 0.00 0.00 0.00 0.00 32 |__ghc_worker 06:42:43 AM - 2850196 0.00 0.00 0.00 0.00 34 |__ghc_worker 06:42:43 AM - 2850197 0.00 0.00 0.00 0.00 35 |__ghc_worker 06:42:43 AM - 2850198 0.00 0.00 0.00 0.00 10 |__ghc_worker 06:42:43 AM - 2850199 0.00 0.00 0.00 0.00 19 |__ghc_worker 06:42:43 AM - 2850295 0.00 0.00 0.00 0.00 13 |__ghc_worker 06:42:43 AM - 2861009 0.00 0.00 0.00 0.00 34 |__ghc_worker 06:42:43 AM - 2861010 0.00 0.00 0.00 0.00 35 |__ghc_worker }}} {{{ $ pidstat -t -p $(pidof ghc) | grep ghc_worker 06:43:37 AM - 2848953 0.00 0.00 0.00 0.00 21 |__ghc_worker 06:43:37 AM - 2848954 0.00 0.00 0.00 0.00 31 |__ghc_worker 06:43:37 AM - 2848955 0.00 0.00 0.00 0.00 9 |__ghc_worker 06:43:37 AM - 2848957 0.00 0.00 0.00 0.00 9 |__ghc_worker 06:43:37 AM - 2848958 0.00 0.00 0.00 0.00 22 |__ghc_worker 06:43:37 AM - 2848959 0.00 0.00 0.00 0.00 37 |__ghc_worker 06:43:37 AM - 2848960 0.00 0.00 0.00 0.00 29 |__ghc_worker 06:43:37 AM - 2848961 0.00 0.00 0.00 0.00 20 |__ghc_worker 06:43:37 AM - 2848962 0.00 0.00 0.00 0.00 36 |__ghc_worker 06:43:37 AM - 2848963 0.00 0.00 0.00 0.00 3 |__ghc_worker 06:43:37 AM - 2848964 0.00 0.00 0.00 0.00 12 |__ghc_worker 06:43:37 AM - 2848965 0.00 0.00 0.00 0.00 15 |__ghc_worker 06:43:37 AM - 2848966 0.00 0.00 0.00 0.00 24 |__ghc_worker 06:43:37 AM - 2848967 0.00 0.00 0.00 0.00 38 |__ghc_worker 06:43:37 AM - 2848968 0.00 0.00 0.00 0.00 23 |__ghc_worker 06:43:37 AM - 2848969 0.00 0.00 0.00 0.00 1 |__ghc_worker 06:43:37 AM - 2848970 0.00 0.00 0.00 0.00 19 |__ghc_worker 06:43:37 AM - 2850193 0.00 0.00 0.00 0.00 32 |__ghc_worker 06:43:37 AM - 2850196 0.00 0.00 0.00 0.00 34 |__ghc_worker 06:43:37 AM - 2850197 0.00 0.00 0.00 0.00 35 |__ghc_worker 06:43:37 AM - 2850198 0.00 0.00 0.00 0.00 30 |__ghc_worker 06:43:37 AM - 2861009 0.00 0.00 0.00 0.00 17 |__ghc_worker 06:43:37 AM - 2861010 0.00 0.00 0.00 0.00 19 |__ghc_worker 06:43:37 AM - 2862954 0.00 0.00 0.00 0.00 2 |__ghc_worker 06:43:37 AM - 2862956 0.00 0.00 0.00 0.00 26 |__ghc_worker }}} The sets of threads are changing on every suspend, unsuspend combination. This is really visible when running in gdb with -j40, gdb just spews threads getting spawned and killed: {{{ [Thread 0x7f0b767fc700 (LWP 2881933) exited] [New Thread 0x7f0b767fc700 (LWP 2881940)] [New Thread 0x7f0cc2cfd700 (LWP 2881941)] [Thread 0x7f0b76ffd700 (LWP 2881928) exited] [New Thread 0x7f0b7dffb700 (LWP 2881942)] [New Thread 0x7f0b76ffd700 (LWP 2881943)] [New Thread 0x7f0b7ffff700 (LWP 2881944)] [Thread 0x7f0b777fe700 (LWP 2881932) exited] [Thread 0x7f0b77fff700 (LWP 2881931) exited] [Thread 0x7f0b7d7fa700 (LWP 2881927) exited] [Thread 0x7f0b7f7fe700 (LWP 2881926) exited] [New Thread 0x7f0b7f7fe700 (LWP 2881945)] [New Thread 0x7f0b7d7fa700 (LWP 2881948)] [Thread 0x7f0cc2cfd700 (LWP 2881941) exited] [Thread 0x7f0b75ffb700 (LWP 2881938) exited] [New Thread 0x7f0cc2cfd700 (LWP 2881949)] [Thread 0x7f0b767fc700 (LWP 2881940) exited] [New Thread 0x7f0b767fc700 (LWP 2881950)] [New Thread 0x7f0b75ffb700 (LWP 2881951)] [New Thread 0x7f0b77fff700 (LWP 2881952)] [Thread 0x7f0b757fa700 (LWP 2881939) exited] [Thread 0x7f0b7d7fa700 (LWP 2881948) exited] [New Thread 0x7f0b757fa700 (LWP 2881953)] [Thread 0x7f0b7effd700 (LWP 2881936) exited] [Thread 0x7f0cc3cff700 (LWP 2881937) exited] [New Thread 0x7f0cc3cff700 (LWP 2881954)] [New Thread 0x7f0b7effd700 (LWP 2881955)] [New Thread 0x7f0b7d7fa700 (LWP 2881956)] [Thread 0x7f0b7dffb700 (LWP 2881942) exited] [New Thread 0x7f0b777fe700 (LWP 2881957)] [New Thread 0x7f0b7dffb700 (LWP 2881958)] [Thread 0x7f0b76ffd700 (LWP 2881943) exited] [New Thread 0x7f0b76ffd700 (LWP 2881959)] [Thread 0x7f0b7e7fc700 (LWP 2881935) exited] [Thread 0x7f0b7effd700 (LWP 2881955) exited] [New Thread 0x7f0b7effd700 (LWP 2881962)] [New Thread 0x7f0b7e7fc700 (LWP 2881963)] [Thread 0x7f0b7f7fe700 (LWP 2881945) exited] [New Thread 0x7f0b7f7fe700 (LWP 2881964)] [New Thread 0x7f0b7cff9700 (LWP 2881965)] [Thread 0x7f0b75ffb700 (LWP 2881951) exited] [Thread 0x7f0b7dffb700 (LWP 2881958) exited] [Thread 0x7f0cc3cff700 (LWP 2881954) exited] [New Thread 0x7f0cc3cff700 (LWP 2881967)] [New Thread 0x7f0b7dffb700 (LWP 2881968)] [Thread 0x7f0b777fe700 (LWP 2881957) exited] [Thread 0x7f0b757fa700 (LWP 2881953) exited] [Thread 0x7f0cc2cfd700 (LWP 2881949) exited] [Thread 0x7f0b7ffff700 (LWP 2881944) exited] [New Thread 0x7f0cc2cfd700 (LWP 2881969)] [Thread 0x7f0b7e7fc700 (LWP 2881963) exited] [Thread 0x7f0b767fc700 (LWP 2881950) exited] [New Thread 0x7f0b767fc700 (LWP 2881970)] [New Thread 0x7f0b7e7fc700 (LWP 2881971)] [Thread 0x7f0b77fff700 (LWP 2881952) exited] [New Thread 0x7f0b7ffff700 (LWP 2881972)] [New Thread 0x7f0b77fff700 (LWP 2881973)] [New Thread 0x7f0b757fa700 (LWP 2881974)] [Thread 0x7f0b7dffb700 (LWP 2881968) exited] [New Thread 0x7f0b7dffb700 (LWP 2881975)] [Thread 0x7f0cc2cfd700 (LWP 2881969) exited] [New Thread 0x7f0cc2cfd700 (LWP 2881976)] [Thread 0x7f0b76ffd700 (LWP 2881959) exited] [Thread 0x7f0b757fa700 (LWP 2881974) exited] [New Thread 0x7f0b76ffd700 (LWP 2881977)] [New Thread 0x7f0b757fa700 (LWP 2881978)] [New Thread 0x7f0b777fe700 (LWP 2881979)] [Thread 0x7f0b7effd700 (LWP 2881962) exited] [New Thread 0x7f0b7effd700 (LWP 2881980)] [Thread 0x7f0b7ffff700 (LWP 2881972) exited] [Thread 0x7f0b7e7fc700 (LWP 2881971) exited] [Thread 0x7f0b77fff700 (LWP 2881973) exited] [New Thread 0x7f0b77fff700 (LWP 2881981)] [Thread 0x7f0b7d7fa700 (LWP 2881956) exited] [New Thread 0x7f0b7d7fa700 (LWP 2881982)] [New Thread 0x7f0b7e7fc700 (LWP 2881983)] [Thread 0x7f0cc2cfd700 (LWP 2881976) exited] [New Thread 0x7f0cc2cfd700 (LWP 2881984)] [New Thread 0x7f0b7ffff700 (LWP 2881985)] [New Thread 0x7f0b75ffb700 (LWP 2881986)] [Thread 0x7f0b7dffb700 (LWP 2881975) exited] [New Thread 0x7f0b7dffb700 (LWP 2881987)] [New Thread 0x7f0b74ff9700 (LWP 2881988)] [Thread 0x7f0b777fe700 (LWP 2881979) exited] [Thread 0x7f0b7effd700 (LWP 2881980) exited] [Thread 0x7f0b76ffd700 (LWP 2881977) exited] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10587> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10612: Progain 350 new Muscle Product!
by GHC 07 Jul '15

07 Jul '15

#10612: Progain 350 new Muscle Product! -------------------------------------+------------------------------------- Reporter: | Owner: ddeserddeser | Status: new Type: bug | Milestone: Priority: lowest | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Progain 350 supplement Progain 350 supplement is a wholly naturally supplement for people who are looking to gain strong and lean muscles within no time. the supplement is manufactured by highly professional doctors in some of the country’s best equipped scientific laboratories to provide nothing but the best results and male performance. Designed to boost the amount of testosterone in the body, the [http://www.progain-350.reviews/ Progain 350] dietary supplement is an ultimate answer for young and older men who would love to improve their bodies without regrets. The supplement is also an excellent option for people who lift a lot of weights and work out hard already, but who have not seem meaningful results. The Benefits of Progain 350 Both young and older men who are interested in impressing women with their ripped abs and performance in the bedroom will certainly find the supplement beneficial. People who desire well-defined muscles that make their muscles more visible will see the results, as well. The supplement is also recommendable for for for people who spend a significant amount of time in the gym but haven’t seen any meaningful results. By shortening healing time and endurance, the supplement allows the user to exercise more, build muscles while shedding pounds faster. Healing time is reduced, so muscle pains can also be avoided, even after going through a thorough two-hour endurance training. The Ingredients of Progain 350 The Progain 350 dietary supplement is developed to give a 100% natural solution for men who intend to break up with steroids, and have well- defined, lean muscles. [http://www.progain-350.reviews/progain-350-ingredients/ Progain 350] has the Nitric Oxide compound, which is the key supplement for building strong, lean muscles. Known Side Effects as we speak, there aren’t any serious side effects of Progain 350. Because Progain 350 is wholly natural, it does not come with side effects that are caused by synthetic drugs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10612> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5113: Huge performance regression of 7.0.2, 7.0.3 and HEAD over 7.0.1 and 6.12 (MonoLocalBinds)
by GHC 07 Jul '15

07 Jul '15

#5113: Huge performance regression of 7.0.2, 7.0.3 and HEAD over 7.0.1 and 6.12 (MonoLocalBinds) -------------------------------------+------------------------------------- Reporter: | Owner: daniel.is.fischer | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.0.3 Component: Compiler | Keywords: Resolution: fixed | performance, MonoLocalBinds Operating System: Linux | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | perf/should_run/T5113 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): It seems to me like the fix for #10527 is a bit questionable. I may be missing something but I don't see how arguments could possibly get to the rebuilder (which is responsible for trying rewrite rules) as we now simply perform a bunch of substitutions on them with `substExprS` instead of passing them to`simplExpr`. Surely I'm missing something as one would think this would result in massive a performance regression if it really were the case. Simon, perhaps you can explain how you intended this to work? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5113#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0