#12221: GHC's signal handlers break C-c C-c force terminate
-------------------------------------+-------------------------------------
Reporter: ezyang | Owner: ezyang
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.0.1
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
GHC RTS has a policy that if it can't neatly shut off after the first C-c,
it will forcibly terminate after the second one.
This works all very well, until we reprogram the signal handler:
{{{
import Panic
main = do
installSignalHandlers
let f x | x == 0 = 0 :: Int
| otherwise = f (x + 1)
print (f (1 :: Int))
}}}
Compile this with
{{{
ezyang@sabre:~$ ghc-8.0 --make M.hs -O -package ghc
ezyang@sabre:~$ ./M
^C^C^C^C^C^C^C^C^Z
[1]+ Stopped ./M
ezyang@sabre:~$ kill -9 %1
[1]+ Killed ./M
}}}
So yeah, that's a pain. What this means is that if GHC itself infinite
loops, you can't ^C it.
Maybe #10686 is exactly this, but my diagnosis doesn't seem to be
consistent with their workaround in Leksah. In particular, this program
still does not accept C-C:
{{{
import Panic
import System.Posix.Signals
(emptySignalSet, sigINT, addSignal, unblockSignals)
main = do
installSignalHandlers
unblockSignals $ addSignal sigINT emptySignalSet
let f x | x == 0 = 0 :: Int
| otherwise = f (x + 1)
print (f (1 :: Int))
}}}
#4162 is people asking GHC to NOT install signal handlers unless we are
running GHCi; this would also solve the problem.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12221>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#10686: Process stops responding to sigINT
-------------------------------------+-------------------------------------
Reporter: hamish | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.10.1
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Revisions: |
-------------------------------------+-------------------------------------
Every now and then the leksah-server process has required a kill -9 it to
get rid of it. Now Leksah is using the threaded RTS it seems to be
happening in Leksah too. It is worse in Leksah because child processes
inherit the behaviour and do not terminate when sent Leksah sends them
sigINT (which Leksah does very frequently).
Once the problem arrises it continues until the Leksah is restarted.
Both leksah-server and Leksah start child processes using the process
package.
I think process package and the GHC GC both call blockUserSignals and it
only has one place to store savedSignals. My guess is that two calls go
into blockUserSignals from different threads before unblockUserSignals is
called on either. The result is that when unblockUserSignals is called it
does nothing (because savedSignals was overwritten).
Perhaps savedSignals could use some kind of thread local storage?
Also docs seem to indicate sigprocmask should not be used at all in
multithreaded processes. Perhaps the GHC RTS should use
pthread_sigprocmask instead?
If the calling process delegates Ctrl+C the problem might be largely
hidden. The sigINT signal is enabled again in the child fork and the
parent will get an exception if the child is terminated with a sigINT.
However I believe the parent is still left in a state where it will no
longer respond to sigINT if the child process terminates normally
(assuming two calls in a row were made to blockUserSignals at some point).
The work around for now in Leksah is to reenable sigINT before each
createProcess call.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10686>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#12191: 7% allocation regression in Haddock performance tests
-------------------------------------+-------------------------------------
Reporter: bgamari | Owner:
Type: task | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.0.1
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: Compile-time
Unknown/Multiple | performance bug
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
One of the commits below is responsible for a rather significant
[[https://perf.haskell.org/ghc/#revision/d55a9b4fd5a3ce24b13311962bca66155b17…]]
in the `haddock.Cabal` and `haddock.compiler` testcases,
{{{
d55a9b4fd5a3ce24b13311962bca66155b17a558
0497ee504cc9ac5d6babee9b98bf779b3fc50b98
586d55815401c54f4687d053fb033e53865e0bf1
7de776cfe7825fca6a71fe6b3854c3c86bf9ca12
5cee88d766723929f789ffcd2ef24d8b5ef62a16
1dcb32ddba605bced2e0e0ce3f52b58e8ff33f5b
921ebc9f0854d033cbafd43d3b2c5ba679c27b3c
e064f501d76c208ddab3c3be551ffe5167d7974f
8104f7c674d7ef2db0c25312f48763202dcef57f
599d912f0b85583e389661d85ed2f198e2621bb0
15fc52819c440f9e9b91ce92fcfda3c264cbe1c1
1f661281a23b6eab83a1144c43e464c0e2d2195a
35c9de7ca053eda472cb446c53bcd2007bfd8394
7afb7adf45216701e4f645676ecc0668f64b424d
c28dde37f3f274a2a1207dd4e175ea79769f5ead
15b9bf4ba4ab47e6809bf2b3b36ec16e502aea72
}}}
It would be nice to identify which of these is the culprit. The fix in
`d55a9b4fd5a3ce24b13311962bca66155b17a558` will need to be applied on top
of each of these to allow things to build.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12191>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4012: Compilation results are not deterministic
-------------------------------------+-------------------------------------
Reporter: kili | Owner: niteria
Type: bug | Status: new
Priority: high | Milestone: 8.2.1
Component: Compiler | Version: 6.12.2
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: Other | Test Case:
Blocked By: 11362 | Blocking:
Related Tickets: #10424 | Differential Rev(s): Phab:D910,
| Phab:D1073, Phab:D1133, Phab:D1192,
| Phab:D1268, Phab:D1360, Phab:D1373,
Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468,
DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508
-------------------------------------+-------------------------------------
Comment (by Bartosz Nitka <niteria@…>):
In [changeset:"348f2dbb835b1208f601bb1e8daa1d1d54507eda/ghc"
348f2dbb/ghc]:
{{{
#!CommitTicketReference repository="ghc"
revision="348f2dbb835b1208f601bb1e8daa1d1d54507eda"
Make the Ord Module independent of Unique order (2nd try)
The `Ord Module` instance currently uses `Unique`s for comparison.
We don't want to use the `Unique` order because it can introduce
nondeterminism.
This switches `Ord ModuleName` and `Ord UnitId` to use lexicographic
ordering making `Ord Module` deterministic transitively.
I've run `nofib` and it doesn't make a measurable difference.
See also Note [ModuleEnv determinism and performance].
This fixes #12191 - the regression, that the previous version of this
patch had.
Test Plan:
./validate
run nofib: P112
Reviewers: simonmar, bgamari, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2354
GHC Trac Issues: #4012, #12191
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:211>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#11081: Implement Introspective Template Haskell
-------------------------------------+-------------------------------------
Reporter: goldfire | Owner:
Type: feature | Status: new
request |
Priority: normal | Milestone: ⊥
Component: Template | Version: 7.10.2
Haskell |
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
| TemplateHaskell/Introspective
-------------------------------------+-------------------------------------
This ticket is to track commentary and reactions to
TemplateHaskell/Introspective, and to help the proposal not get lost.
Contrary to the title of this ticket, it is not yet resolved that
Introspective Template Haskell should ever be implemented. But with some
of the support that it's gotten, it seemed appropriate to make a ticket.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11081>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7198: New codegen more than doubles compile time of T3294
-------------------------------------+-------------------------------------
Reporter: simonmar | Owner: simonmar
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.4.2
(CodeGen) |
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Compile-time | Unknown/Multiple
performance bug | Test Case:
Blocked By: | Blocking:
Related Tickets: #4258 | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by simonpj):
Distinguish between
* Global registers, like R1, Sp, which are part of the calling
convention, and live in fixed places
* Local registers, written `x`, `y`, etc in Cmm, which are just like
local variables in a programming language. There are an infinite number
of them. You can't take their address.
We do indeed generate loads into a local register at the start; but we
expect those loads to sink downstream to their use sites, so they don't
necessarily cause register pressure.
It's not safe to replace them with memory loads. Example
{{{
x = R1[4]
call f( p, q )
...use x...
}}}
We must save `x` on the stack across the call. R1 is involved in f's
calling convention, so it may well change a lot. Indeed any modification
to R1 is going to invalidate your saved "x = R1[4]" delayed load.
Plus the double-load efficiency problem that Simon mentions.
Better to load into a local variable and then sink it.
Does that make sense?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7198#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#5987: Too many symbols in ghc package DLL
---------------------------------+----------------------------------------
Reporter: igloo | Owner: Phyx-
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.5
Resolution: | Keywords:
Operating System: Windows | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking: 5355
Related Tickets: | Differential Rev(s):
Wiki Page: |
---------------------------------+----------------------------------------
Comment (by simonmar):
I second what @simonpj said, amazing job, thanks for working on this!
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:57>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#8713: libdl, libpthread may be unwanted too
-------------------------------------+-------------------------------------
Reporter: ip1981 | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: libraries/unix | Version: 7.6.3
Keywords: | Operating System: Other
Architecture: x86_64 (amd64) | Type of failure: GHC doesn't work
Difficulty: Moderate (less | at all
than a day) | Test Case:
Blocked By: | Blocking:
Related Tickets: |
-------------------------------------+-------------------------------------
I have GHC on an unusual system [1]
libdl.so.1, librt.so.1 and some others are "filter libraries": they do not
provide real functions (almost all is in libc.so.1), but to make thing
work libFOO.so are GNU ld linker scripts: thus linking is successful,
libFOO.so.1 is not linked in :-)
Unfortunately, runtime linker (ld.so.1) does not understand GNU ld linker
scripts. And I get errors like this:
{{{
# ghci -package unix
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package bytestring-0.10.0.2 ... linking ... done.
Loading package old-locale-1.0.0.5 ... linking ... done.
Loading package time-1.4.0.1 ... linking ... done.
Loading package unix-2.7.0.0 ... <command line>: can't load .so/.DLL for:
/usr/lib/gcc/x86_64-pc-solaris2.11/4.7/../../../x86_64-illumos/libdl.so
(ld.so.1: ghc: fatal: /usr/lib/gcc/x86_64-pc-
solaris2.11/4.7/../../../x86_64-illumos/libdl.so: unknown file type)
}}}
The unix package v2.6 had the same issue with librt.so too, in version 2.7
libdl.so remains.
I use the attached patch for GHC 7.6.3 to fix this issue.
In general I suggest to use AC_SEARCH_LIBS instead of AC_CHECK_LIB
[1] http://osdyson.org
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8713>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#5987: Too many symbols in ghc package DLL
---------------------------------+----------------------------------------
Reporter: igloo | Owner: Phyx-
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.5
Resolution: | Keywords:
Operating System: Windows | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking: 5355
Related Tickets: | Differential Rev(s):
Wiki Page: |
---------------------------------+----------------------------------------
Comment (by Phyx-):
Hi @simonpj,
Sure that won't be a problem, I was already planning on writing an
extended explanation of the implementation so make the code review easier
and for if someone else needs to take a look at the implementation in the
future :)
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:56>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#5987: Too many symbols in ghc package DLL
---------------------------------+----------------------------------------
Reporter: igloo | Owner: Phyx-
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.5
Resolution: | Keywords:
Operating System: Windows | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking: 5355
Related Tickets: | Differential Rev(s):
Wiki Page: |
---------------------------------+----------------------------------------
Comment (by simonpj):
Phyx, that sounds amazing! I have not idea what you are talking about --
I do not know enough about Windows and import libraries -- but for the
first time we have someone who DOES actually understand looking hard at
it. I always HATED the dll-split thing. Thank you.
Maybe before you are done you can write a Duffers Guide to what people
need to know about Windows linking to make sense of the implementation
strategies you are using.
With thanks
Simon
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:55>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
