1. Summarise the issue (what were doing, what went wrong?)

I was trying to commit a change but I got an error message instead:

~/bin (master|✚10…) ❯❯❯ darcs record -m "next commit"
addfile ./.gitignore
fish: Job 2, 'darcs record -m "next commit"' terminated by signal
SIGABRT (Abort)

I tailed dmesg and saw this line:

darcs(67403): mprotect W^X violation

Here's some background on why this is a problem on OpenBSD specifically:

http://undeadly.org/cgi?action=article&sid=20160527203200

The workaround is installing darcs on an OpenBSD partition that allows
W^X violations or use a different OS that's less picky about these sort
of things.

2. What behaviour were you expecting instead?

The commit would succeed without error.

3. What darcs version are you using? (Try: darcs --exact-version)

~/bin (master|✚10…) ❯❯❯ darcs --exact-version
darcs compiled on Jan 29 2017, at 22:51:09

Context:

[TAG 2.12.0
Guillaume Hoffmann <guillaumh@gmail.com>**20160429142058
 Ignore-this: 5c8cbe0424942686a2168f9e6fd8e35d
]

Compiled with:

HTTP-4000.3.5
array-0.5.1.0
async-2.1.1
attoparsec-0.13.1.0
base-4.8.2.0
base16-bytestring-0.1.1.6
binary-0.7.5.0
bytestring-0.10.6.0
containers-0.5.6.2
cryptohash-0.11.9
data-ordlist-0.4.7.0
directory-1.2.2.0
fgl-5.5.3.0
filepath-1.4.0.0
graphviz-2999.18.1.2
hashable-1.2.4.0
haskeline-0.7.3.0
html-1.0.1.2
mmap-0.5.9
mtl-2.2.1
network-2.6.3.1
network-uri-2.6.1.0
old-time-1.1.0.3
parsec-3.1.11
process-1.2.3.0
random-1.1
regex-applicative-0.3.3
regex-compat-tdfa-0.95.1.4
sandi-0.3.6
tar-0.5.0.3
terminfo-0.4.0.2
text-1.2.2.1
time-1.5.0.1
transformers-0.4.2.0
transformers-compat-0.4.0.4
unix-2.7.1.0
unix-compat-0.4.1.4
utf8-string-1.0.1.1
vector-0.11.0.0
zip-archive-0.2.3.7
zlib-0.6.1.2

4. What operating system are you running?

OpenBSD rain.ggr.com 6.0 GENERIC.MP#0 amd64

...

If a darcs dev is interested in working on a fix for this, I'm happy to
create a VirtualBox or Qemu VM image with OpenBSD setup, darcs
installed, and a darcs repo setup that repros the issue. Just say the word.

Hi,

On Tue, Jan 31, 2017 at 04:48:37PM +0000, Scott Bonds wrote:
> New submission from Scott Bonds <scott@ggr.com>:
> 
> 1. Summarise the issue (what were doing, what went wrong?)
> 
> I was trying to commit a change but I got an error message instead:
> 
> ~/bin (master|✚10…) ❯❯❯ darcs record -m "next commit"
> addfile ./.gitignore
> fish: Job 2, 'darcs record -m "next commit"' terminated by signal
> SIGABRT (Abort)
> 
> I tailed dmesg and saw this line:
> 
> darcs(67403): mprotect W^X violation
> 
> Here's some background on why this is a problem on OpenBSD specifically:
> 
> http://undeadly.org/cgi?action=article&sid=20160527203200
> 
> The workaround is installing darcs on an OpenBSD partition that allows
> W^X violations

Indeed. When installing darcs from the official OpenBSD package
collection, the binary will end up in /usr/local/bin, and since
there are still some other programs with W^X violations (such as
chromium for example) it's probably ok to mount /usr/local with the
wxallowed option.

But when you're building darcs yourself (as seems to be the case
here, because the OpenBSD darcs package is still at 2.10): yes,
you'll have to install it on a separate filesystem with the wxallowed
option.

And please be aware that this isn't a problem of darcs itself, but
of ghc's runtime system. I tried to patch that last year, but failed
badly :-(

At the moment, I try to update the Haskell ports for OpenBSD to use
at least ghc-8.0.1, but that's an annoying work, because many of
the libraries we have in the OpenBSD ports tree (including those
darcs depends on) need updates, too (and sometimes patches), so
I've no idea when I'm ready to commit this update. And only after
that I'll start to look at the W^X violations in ghc again, because
there are too many changes in ghc's RTS between 7.10 and 8.0.

> or use a different OS that's less picky about these sort
> of things.

On the long term, every OS should (and hopefully will) be even more
picky and disable W|X completely. Even if there are still some knobs
to turn W^X enforcement off or *some* programs, doing so for a tool
like darcs which is typically exposed to the network (when working
with remote repositories) isn't a wise decision, IMHO.

Ciao,
	Kili

If it is in the ghc runtime we can't do anything about this.