For years (since 4.2) I've used iBCS2 to run MS FoxPro Unix 2.6 without any problems. I am setting up a new machine and have installed 8.1. I have iBCS2 load via klms: parkrow4# kldstat Id Refs Address Size Name 1 8 0xc0400000 bb5504 kernel 2 2 0xc0fb6000 cc94 ibcs2.ko 3 1 0xc0fc3000 3028 ibcs2_coff.ko When I run the binary I get a segmentation fault message. parkrow4# file foxpro.pr foxpro.pr: 80386 COFF executable parkrow4# truss ./foxpro.pr truss: execution type IBCS2 COFF is not supported -- using FreeBSD a.out: Unknown error: 0 SIGNAL 11 (SIGSEGV) How-To-Repeat: See notes above. As a precaution I have done a complete reinstall after checking the SHA256. I also uses Memtest86+ to do a hardware test. There are some other similar reports. http://forums.freebsd.org/showthread.php?t=19764
Responsible Changed From-To: freebsd-bugs->freebsd-emulation Over to maintainer(s).
This sounds to me like the same problem that was later solved in the following discussion in 2013: https://lists.freebsd.org/pipermail/freebsd-hackers/2013-October/043615.html The solution was to run "sysctl security.bsd.map_at_zero=1” or add “security.bsd.map_at_zero=1“ to /etc/sysctl.conf. The problem was that COFF files want to load at address 0, which is no longer allowed by default. The executable code ends up on the wrong address, and crashes. So it is not really a bug, just difficult to use. There was some follow-up discussion that this setting is documented in aout(4), but that some more documentation and clearer messages might be added for COFF (or iBCS2) too. Or make the COFF loader allow this automatically. Most people would probably never find this out for themselves, and would just conclude that iBCS2 is broken, so I think some of those suggestions should be undertaken. It took me a long time to find this by googling too.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
As per the message from Kristoffer Eriksson, the solution is to run "sysctl security.bsd.map_at_zero=1” or add “security.bsd.map_at_zero=1“ to /etc/sysctl.conf. So not a bug.