[GHC] #14825: Access violation on Windows is not propagated to the OS

[GHC]

#14825: Access violation on Windows is not propagated to the OS
-------------------------------------+-------------------------------------
        Reporter:  varosi            |                Owner:  (none)
            Type:  feature request   |               Status:  closed
        Priority:  normal            |            Milestone:
       Component:  Runtime System    |              Version:  8.2.2
      Resolution:  duplicate         |             Keywords:
Operating System:  Windows           |         Architecture:  x86_64
 Type of failure:  Debugging         |  (amd64)
  information is incorrect           |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #13911            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by Phyx-):

 * status:  new => closed
 * resolution:   => duplicate
 * related:   => #13911


Comment:

 Hi,

 I'm closing this as a dupe.

 Couple of things however:

 > The correct way on Windows is such exceptions to be propagated to the
 operating system.

 No it's not. An application is perfectly fine handling it's own
 exceptions. That's why the OS makes a distinction between `Unhandled` and
 `Handled` exceptions.

 > This way we will attach a debugger to the process and it'll get and
 visualize where the exception happened.

 This is also not accurate, first chance exceptions are always handled
 before all user exception handlers. GHC uses `VEH` handlers up to 8.4 and
 from then on `VCH`.

 The documentation clearly states `Vectored handlers are called in the
 order that they were added, after the debugger gets a first chance
 notification, but before the system begins unwinding the stack.` (see
 https://msdn.microsoft.com/en-
 us/library/windows/desktop/ms681420(v=vs.85).aspx)

 If a debugger is attached, it will *always* get the first chance to handle
 exceptions! If it wants to.

 For instance

 {{{
 module Main where

 import Foreign

 main :: IO ()
 main = do x <- peek nullPtr
           print (x :: Int)
 }}}

 compiling and attaching a debugger

 {{{
 Tamar at Rage ~/ghc2> ghc noexception.hs -fforce-recomp
 [1 of 1] Compiling Main             ( noexception.hs, noexception.o )
 Linking noexception.exe ...

 Tamar at Rage ~/ghc2> gdb --ex r --args noexception.exe
 GNU gdb (GDB) 7.11.1
 Copyright (C) 2016 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later
 <http://gnu.org/licenses/gpl.html>
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
 and "show warranty" for details.
 This GDB was configured as "x86_64-pc-msys".
 Type "show configuration" for configuration details.
 For bug reporting instructions, please see:
 <http://www.gnu.org/software/gdb/bugs/>.
 Find the GDB manual and other documentation resources online at:
 <http://www.gnu.org/software/gdb/documentation/>.
 For help, type "help".
 Type "apropos word" to search for commands related to "word"...
 Traceback (most recent call last):
   File "<string>", line 3, in <module>
 ImportError: No module named libstdcxx.v6.printers
 /etc/gdbinit:6: Error in sourced command file:
 Error while executing Python code.
 Reading symbols from noexception.exe...done.
 Starting program: /home/Tamar/ghc2/noexception.exe
 [New Thread 47004.0x7284]
 [New Thread 47004.0xb4ac]
 [New Thread 47004.0x5580]
 [New Thread 47004.0x9d40]
 [New Thread 47004.0x1b38]

 Thread 1 received signal SIGSEGV, Segmentation fault.
 0x0000000000402879 in c6BK_info ()
 (gdb)
 }}}

 as you can see the debugger clearly breaks.

 {{{
 Tamar at Rage~/ghc2> ./noexception.exe
 Segmentation fault/access violation in generated code
 }}}

 without the debugger the exception handler runs.

 > Currently GHC runtime is catching the exception, skip its source
 information and present that uninformative message to the user.

 The reason the error is uninformative is because the location of your
 segfault occurred in a location for which there is no source information.
 The Haskell compiler can only emit DWARF at best so debugging is just more
 difficult on Windows.

 When running in ghci GHC 8.4 and newer will attempt to reconstruct a
 stack. It will also allow you to opt out of exception handling all
 together.

 For older (and compatible with newer) GHCs you can reasonably easily opt-
 out using FFI:

 {{{
 module Main where

 import Foreign

 foreign import ccall "__unregister_hs_exception_handler"
 disableExceptionHandler :: IO ()

 main :: IO ()
 main = do disableExceptionHandler
           x <- peek nullPtr
           print (x :: Int)
 }}}

 and you clearly get a second chance exception now

 {{{
 Tamar at Rage ~/ghc2> ./noexception.exe
 fish: “./noexception.exe” terminated by signal SIGSEGV (Address boundary
 error)
 }}}


 This isn't supported, but it's an easy way to disable the handling on
 older compilers.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14825#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler