#16302: A non-function coerced to a function can cause a stg_ap_v_ret -------------------------------------+------------------------------------- Reporter: WheatWizard | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by WheatWizard: Old description:

If you create an function by unsafe coercing a non-function you can get some strange functions. If you then take one of these function and apply it something it crashes with a {{{stg_ap_pp_ret}}}. Here is a pretty minimal example.

{{{ import Unsafe.Coerce main=(unsafeCoerce()::a->IO())1 }}}

You can reproduce it online here: https://tio.run/##y0gszk7Nyfn/PzO3IL@oRCE0rzgxLVXPOT@1KDmVKzcxM89WoxQsBhHS0L...

Here is another one:

{{{ import Unsafe.Coerce g=unsafeCoerce()::a->a main=print$g(g)1 }}}

If you coerce functions this doesn't appear to happen.

For example:

{{{ import Unsafe.Coerce main=(unsafeCoerce id::a->IO())1 }}}

is a fine program. Sometimes this causes a segmentation fault (particularly with higher airity functions):

{{{ import Unsafe.Coerce main=(unsafeCoerce(+)::a->IO())1 }}}

but I've never gotten it to make a {{{stg_ap_pp_ret}}}.

New description: If you create an function by unsafe coercing a non-function you can get some strange functions. If you then take one of these function and apply it something it crashes with a {{{stg_ap_v_ret}}}. Here is a pretty minimal example. {{{ import Unsafe.Coerce main=(unsafeCoerce()::a->IO())1 }}} You can reproduce it online here: https://tio.run/##y0gszk7Nyfn/PzO3IL@oRCE0rzgxLVXPOT@1KDmVKzcxM89WoxQsBhHS0L... Here is another one: {{{ import Unsafe.Coerce g=unsafeCoerce()::a->a main=print$g(g)1 }}} If you coerce functions this doesn't appear to happen. For example: {{{ import Unsafe.Coerce main=(unsafeCoerce id::a->IO())1 }}} is a fine program. Sometimes this causes a segmentation fault (particularly with higher airity functions): {{{ import Unsafe.Coerce main=(unsafeCoerce(+)::a->IO())1 }}} but I've never gotten it to make a {{{stg_ap_v_ret}}}. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16302#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16302: A non-function coerced to a function can cause a stg_ap_v_ret -------------------------------------+------------------------------------- Reporter: WheatWizard | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11826 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid * related: => #11826 Comment: Indeed, once you start using `unsafeCoerce` in a cavalier fashion like this, you're taking your own life into your hands. The fact that it happened to produce a panic is sheer coincidence—it might have done something even stranger, like segfault. For the reasons explained in #11826 and comment:1, I'm going to mark this as not-a-bug unless there's a compelling reason to believe otherwise. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16302#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler