#4505: Segmentation fault on long input (list of pairs)
-------------------------------------+-------------------------------------
Reporter: cathper | Owner: simonmar
Type: bug | Status: new
Priority: highest | Milestone: 7.10.1
Component: Compiler | Version: 7.0.1
Resolution: | Keywords: Segmentation
Operating System: Linux | fault, segfault, long input
Type of failure: Runtime | Architecture: x86_64 (amd64)
crash | Difficulty: Unknown
Test Case: | Blocked By: 4258
Blocking: | Related Tickets:
Differential Revisions: |
-------------------------------------+-------------------------------------
Comment (by snoyberg):
@simonmar: Yes, that's the error message we're seeing at runtime.
Moving this bug from runtime to compile time would be a *huge* advantage
to me. But I agree that it's not worth holding up the release. To clarify:
I would still be very happy to see a fix for this on the 7.8 branch, as we
could build our own GHC binary with the patch.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:29>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4505: Segmentation fault on long input (list of pairs)
-------------------------------------+-------------------------------------
Reporter: cathper | Owner: simonmar
Type: bug | Status: new
Priority: highest | Milestone: 7.10.1
Component: Compiler | Version: 7.0.1
Resolution: | Keywords: Segmentation
Operating System: Linux | fault, segfault, long input
Type of failure: Runtime | Architecture: x86_64 (amd64)
crash | Difficulty: Unknown
Test Case: | Blocked By: 4258
Blocking: | Related Tickets:
Differential Revisions: |
-------------------------------------+-------------------------------------
Comment (by simonmar):
The code that implements the runtime check is still in place, it's only
the compile-time check that we lost. So you don't get a segfault, but you
do get a runtime failure:
{{{
barf("allocation of %ld bytes too large (GHC should have
complained at compile-time)", (long)cap->r.rHpAlloc);
}}}
@snoyberg: do you see this?
Given this, I don't think it's worth holding up 7.8.4. We wouldn't be
fixing the bug, only moving the failure to compile-time.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:28>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4505: Segmentation fault on long input (list of pairs)
-------------------------------------+-------------------------------------
Reporter: cathper | Owner: simonmar
Type: bug | Status: new
Priority: highest | Milestone: 7.10.1
Component: Compiler | Version: 7.0.1
Resolution: | Keywords: Segmentation
Operating System: Linux | fault, segfault, long input
Type of failure: Runtime | Architecture: x86_64 (amd64)
crash | Difficulty: Unknown
Test Case: | Blocked By: 4258
Blocking: | Related Tickets:
Differential Revisions: |
-------------------------------------+-------------------------------------
Changes (by simonpj):
* priority: high => highest
Comment:
I wish this had come up 3 weeks ago when we were triaging tickets for 7.8.
The release candidate for 7.8.4 is out, so it's tough to get anything else
in. Unless you say "this makes 7.8 unusable for my purposes". (This is
the case for 7.8.3, which is why we went ahead with 7.8.4.)
Putting it in would mean a delay of a couple of weeks while (a) Simon re-
instates the previous fix, (b) Austin makes a new release candidate (c)
everyone tests it.
Of course, it's better to delay 7.8.4 than to have to put out 7.8.5. But
if we keep doing that, we never make a release.
My instinct is "too late". But is there strong user sentiment about this
one?
Simon
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:27>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#9582: Associated Type Synonyms do not unfold in InstanceSigs
-------------------------------------+-------------------------------------
Reporter: andreas.abel | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler (Type | Version: 7.8.3
checker) | Operating System:
Keywords: InstanceSigs | Unknown/Multiple
TypeFamilies | Type of failure:
Architecture: Unknown/Multiple | None/Unknown
Difficulty: Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Revisions:
-------------------------------------+-------------------------------------
{{{#!hs
{-# LANGUAGE InstanceSigs, TypeFamilies #-}
class C a where
type T a
m :: T a
instance C Int where
type T Int = String
m :: String
m = "bla"
-- Method signature does not match class; it should be m :: T Int
-- In the instance declaration for ‘C Int’
}}}
As {{{T Int}}} is a synonym of {{{String}}}, {{{m :: String}}} should be a
valid type signature alternative to {{{m :: T Int}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9582>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#9757: Warn about derivable instances
-------------------------------------+-------------------------------------
Reporter: dfeuer | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.9
Keywords: | Operating System:
Architecture: Unknown/Multiple | Unknown/Multiple
Difficulty: Unknown | Type of failure:
Blocked By: | None/Unknown
Related Tickets: | Test Case:
| Blocking:
| Differential Revisions:
-------------------------------------+-------------------------------------
GHC can derive a lot of instances by itself, and can sometimes (with
`GeneralizedNewtypeDeriving`) do so better than anyone else. I'd like to
be able to get a warning about any instance that's "obviously equivalent"
to the one that would be derived, for some suitable values of "obviously"
and "equivalent".
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9757>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4505: Segmentation fault on long input (list of pairs)
-------------------------------------+-------------------------------------
Reporter: cathper | Owner: simonmar
Type: bug | Status: new
Priority: high | Milestone: 7.10.1
Component: Compiler | Version: 7.0.1
Resolution: | Keywords: Segmentation
Operating System: Linux | fault, segfault, long input
Type of failure: Runtime | Architecture: x86_64 (amd64)
crash | Difficulty: Unknown
Test Case: | Blocked By: 4258
Blocking: | Related Tickets:
Differential Revisions: |
-------------------------------------+-------------------------------------
Changes (by snoyberg):
* cc: snoyberg (added)
Comment:
I just ran into this on our code base. Is there any chance of getting a
fix for this into the 7.8 series?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:26>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#3744: Comparisons against minBound/maxBound not optimised for (Int|Word)(8|16|32)
-------------------------------------+-------------------------------------
Reporter: rl | Owner:
Type: feature | Status: new
request | Milestone: 7.10.1
Priority: low | Version: 6.13
Component: Compiler | Keywords:
Resolution: | Architecture: Unknown/Multiple
Operating System: | Difficulty: Unknown
Unknown/Multiple | Blocked By:
Type of failure: Runtime | Related Tickets:
performance bug |
Test Case: |
Blocking: |
Differential Revisions: |
-------------------------------------+-------------------------------------
Changes (by thomie):
* difficulty: => Unknown
* type: bug => feature request
Comment:
Status: see comment:12. Use program from comment:5 to test, and replace
`Int` by `Int8` (`Int64` works since 7.4).
For reference: commit d4781f3e6e8cead1cbeac5337f9f78440c8df8bc
{{{
Author: Michal Terepeta <>
Date: Wed Oct 27 18:40:54 2010 +0000
Optimise comparisons against min/maxBound (ticket #3744).
This optimises away comparisons with minBound or maxBound
that are always false or always true.
}}}
commit fe5821233d439c35c441cfc6c9d2029e5fd01342
{{{
Author: Ian Lynagh <>
Date: Wed Sep 19 22:37:01 2012 +0100
Make some uses of minBound/maxBound use the target Int/Word sizes
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3744#comment:17>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#3739: ghc-cabal mishandles relative paths in arguments
-------------------------------------+-------------------------------------
Reporter: asuffield | Owner:
Type: bug | Status: closed
Priority: low | Milestone: 7.10.1
Component: Build | Version:
System | Keywords:
Resolution: invalid | Architecture: Unknown/Multiple
Operating System: | Difficulty: Unknown
Unknown/Multiple | Blocked By:
Type of failure: | Related Tickets:
None/Unknown |
Test Case: |
Blocking: |
Differential Revisions: |
-------------------------------------+-------------------------------------
Changes (by thomie):
* status: new => closed
* difficulty: => Unknown
* resolution: => invalid
Comment:
`ghc-cabal` is currently only used when
[wiki:Building/Architecture/Idiom/Cabal building] ghc (maybe that was
different 5 years ago?), and ghc builds just fine, so I think we can close
this issue. Also note that ghc's dependency on Cabal is planned to be
removed altogether (#8244).
The cabal user problem of `--package-db` not handling relative paths was
fixed in https://github.com/haskell/cabal/pull/1307. See
[https://github.com/haskell/cabal/issues/1542 cabal #1542],
[https://github.com/haskell/cabal/issues/462 cabal #462] for related cabal
issues.
Please re-open if I'm misunderstanding the problem here.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3739#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#5495: simple program fails with -shared on mac
-------------------------------------+-------------------------------------
Reporter: mwotton | Owner:
Type: bug | Status: new
Priority: low | Milestone: 7.10.1
Component: Compiler | Version: 7.2.1
Resolution: | Keywords:
Operating System: | Architecture: Unknown/Multiple
Unknown/Multiple | Difficulty: Unknown
Type of failure: Compile- | Blocked By:
time crash | Related Tickets:
Test Case: |
Blocking: |
Differential Revisions: |
-------------------------------------+-------------------------------------
Comment (by thomie):
Replying to [comment:9 rwbarton]:
> I'm not sure whether this is a bug at all. You need `-dynamic` also, to
produce object files that can be linked dynamically.
Yes, but igloo would know about that, so we should test if the issue from
comment:3 is resolved.
> Granted, the way that `-shared` and `-dynamic` interact with make mode
is, at best, not obvious.
See #3704, #3713 and #3712 for that.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5495#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
