#15092: Optionally bounds-check primops -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I also frequently need this when debugging memory corruptions (e.g. #15038).
The biggest challenge: SomeException, Typeable, Show, String, CallStack, etc.
I think a hard crash is completely appropriate. Bound violations are
Why is this a challenge? I don't see the relation between with these type classes and array operations. programming errors thus there is no way to safely recover from them, anyway. Agreed, but I think there's another approach: raising an exception. We already raise exceptions for runtime errors like non-exhaustive pattern mathing. We could do the same. We already have the type defined: http://hackage.haskell.org/package/base-4.11.1.0/docs/Control- Exception.html#t:ArrayException For my use case, even just a "out of bounds access!" message would do it so I don't feel strongly either way. Note that currently GHC (in DWARF version) already prints the C stack trace on panic: {{{ Main: internal error: evacuate(static): strange closure type 16583 Stack trace: 0x4b4dfb set_initial_registers (rts/Libdw.c:288.0) 0x7f37ccfb3558 dwfl_thread_getframes (/usr/lib/x86_64 -linux-gnu/libdw-0.165.so) 0x7f37ccfb2faf (null) (/usr/lib/x86_64-linux- gnu/libdw-0.165.so) 0x7f37ccfb32d7 dwfl_getthreads (/usr/lib/x86_64-linux- gnu/libdw-0.165.so) 0x7f37ccfb38e0 dwfl_getthread_frames (/usr/lib/x86_64 -linux-gnu/libdw-0.165.so) 0x4b538d libdwGetBacktrace (rts/Libdw.c:259.0) 0x49ce1c rtsFatalInternalErrorFn (rts/RtsMessages.c:172.0) 0x49cfad barf (rts/RtsMessages.c:48.0) 0x4a162e evacuate (includes/rts/storage/Block.h:175.0) 0x4b765b scavenge_loop (rts/sm/Scav.c:1830.0) 0x4a0532 GarbageCollect (rts/sm/GC.c:1423.0) 0x49bb87 scheduleDoGC (rts/Schedule.c:1814.0) 0x49c8c4 scheduleWaitThread (rts/Schedule.c:558.0) 0x49d450 rts_evalLazyIO (rts/RtsAPI.c:531.0) 0x49d75b hs_main (rts/RtsMain.c:73.0) 0x40d6aa (null) (/home/omer/haskell/corrupted-memory- example/Main) 0x7f37ccbd7830 __libc_start_main (../csu/libc- start.c:325.0) 0x4042f9 _start (/home/omer/haskell/corrupted-memory- example/Main) (GHC version 8.4.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [1] 3391 abort (core dumped) ./Main }}} So we get some information for free already.
My concerns about the "hard crash" approach: the error messages may not be as informative as one might wish
I'm curious what kind of error messages you'd like to get? I think the main problem is for "out of line" array operations like `copyArray#` we'll need one more variant of RTS, so longer GHC boot times, more code to distribute etc. Not sure how to avoid this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15092#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler