ghc, OpenBSD and stack pointer checking
Hi, while working on an ghc update for OpenBSD (to ghc-8.2.2), I tested a diff for OpenBSD which enforces a special mmap(2) option, MAP_STACK for the system stack and, if the check fails, just aborts the process.[1] (Please note that this differs from the meaning of MAP_STACK on some other operating systems) At first, everything looked fine, but later during the build, *sometimes* ghc (to be specific, inplace/lib/bin/ghc-stage2) got aborted after *many* succesfull runs of it (for example, while compiling the bundled haddock and after already a couple of haddock sources had been successfully compiled). So, if the stack pointer checking diff to OpenBSD is correct, and if I'm not running into a completely unrelated problem: does ghc and/or the runtime library sometimes move the system stack pointer to newly allocated/mapped memory? If so, where in the code? Please note: the check happens on traps and system calls, so the doesn't happen when the stack pointer is changed to newly allocated/mapped memory, but after the next trap or system call. Unfurtunately, I was stupid enough to drop my recent build logs and back traces, but they weren't very enlightening, anyway ;-) I may to get some more information tomorrow or on thursday. I'd appreciate any help on this. After all it's probably just a matter of changing one call to mmap(2), shielded by an #ifdef. Ciao and thanks in advance for any help, Kili [1]: https://marc.info/?l=openbsd-tech&m=151572838911297&w=2
Matthias Kilian
Hi,
while working on an ghc update for OpenBSD (to ghc-8.2.2), I tested a diff for OpenBSD which enforces a special mmap(2) option, MAP_STACK for the system stack and, if the check fails, just aborts the process.[1] (Please note that this differs from the meaning of MAP_STACK on some other operating systems)
At first, everything looked fine, but later during the build, *sometimes* ghc (to be specific, inplace/lib/bin/ghc-stage2) got aborted after *many* succesfull runs of it (for example, while compiling the bundled haddock and after already a couple of haddock sources had been successfully compiled).
So, if the stack pointer checking diff to OpenBSD is correct, and if I'm not running into a completely unrelated problem: does ghc and/or the runtime library sometimes move the system stack pointer to newly allocated/mapped memory? If so, where in the code?
As far as I know GHC shouldn't touch x86-64's $rsp at all; we specifically avoid using it for the STG stack to ease FFI. It would be interesting to know what is touching it. Unfortunately, without a tool like rr this may be hard to find. Cheers, - Ben [1] http://rr-project.org/
Hi, On Thu, Jan 18, 2018 at 01:21:27PM -0500, Ben Gamari wrote:
So, if the stack pointer checking diff to OpenBSD is correct, and if I'm not running into a completely unrelated problem: does ghc and/or the runtime library sometimes move the system stack pointer to newly allocated/mapped memory? If so, where in the code?
As far as I know GHC shouldn't touch x86-64's $rsp at all; we specifically avoid using it for the STG stack to ease FFI.
Thanks for the information.
It would be interesting to know what is touching it. Unfortunately, without a tool like rr this may be hard to find.
I doubt it's easy to get rr ported to OpenBSD, so all I can think of at the moment is ktracing every single invocation of ghc during a build (should be relatively easy by patching the ghc wrapper script) and -- after an abort happended, look at the trace to see wether the current stack had been mmapped at all late during the process. At the moment, I'm busy updating all the haskell libraries and tools offically available as OpenBSD packages, but I hope to get back to debugging/tracing in a few days. Ciao, Kili
ho, On Mon, Jan 22, 2018 at 09:52:01PM +0100, Matthias Kilian wrote:
On Thu, Jan 18, 2018 at 01:21:27PM -0500, Ben Gamari wrote:
So, if the stack pointer checking diff to OpenBSD is correct, and if I'm not running into a completely unrelated problem: does ghc and/or the runtime library sometimes move the system stack pointer to newly allocated/mapped memory? If so, where in the code?
As far as I know GHC shouldn't touch x86-64's $rsp at all; we specifically avoid using it for the STG stack to ease FFI.
Thanks for the information.
Little update, in case anyone is interested: with the latest version of the diff[1] to OpenBSD, out ghc port and all the hs-ports build and work fine. So, yes, bug in the early diff, or solar activity during my tests ;-) Ciao, Kili [1] https://marc.info/?l=openbsd-tech&m=152035796722258&w=2
participants (2)
-
Ben Gamari -
Matthias Kilian