Heh, ok, segfaults themselves are a red herring. More precisely: The operational semantics for a SafeIO language should always accurately model its memory state. The application should not compute (take a step in the semantics) in a way that exposes corrupt memory or arbitrary undefined behavior. Nor should it violate the memory model.
Moving immediately to the "Terminated" state is fine, whether it be due to out-of-memory, kill -SEGV, cosmic rays, or hardware failure. An FFI call that corrupts memory is bad (may result in arbitrary behavior, not just termination) as is ptrace'ing. Naturally, all Unsafe code is part of the TCB, as is the OS and GHC, and low-level data structure libs and bindings. It's a big TCB. Still, it's something to be able to write an app that doesn't automatically get added to this TCB just by virtue of being an *app* (main::IO). On Tue, Aug 9, 2016 at 10:52 PM, Brandon Allbery <allber...@gmail.com> wrote: > On Tue, Aug 9, 2016 at 4:19 PM, Edward Z. Yang <ezy...@mit.edu> wrote: > >> If you can execute subprocesses, you could always spawn gdb to >> attach via ptrace() to the parent process and then poke around >> memory. >> > > Don't even need that if you're just talking segfaults, you can always > spawn a subprocess "kill -SEGV $PPID" :) > > Unless you have full control over all the code that could be run in > subprocesses, it's not going to be safe much less Safe. > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs