[GHC] #15092: Optionally bounds-check primops
GHC
ghc-devs at haskell.org
Fri Apr 27 07:56:53 UTC 2018
#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.
Why is this a challenge? I don't see the relation between with these type
classes and array operations.
> I think a hard crash is completely appropriate. Bound violations are
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
More information about the ghc-tickets
mailing list