Bug 255964 - net-p2p/transmission-remote-gui: fails to start when W^X protection is activated
Summary: net-p2p/transmission-remote-gui: fails to start when W^X protection is activated
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Many People
Assignee: Jose Alonso Cardenas Marquez
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-18 05:45 UTC by Andrey Korobkov
Modified: 2021-07-31 19:34 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (acm)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrey Korobkov 2021-05-18 05:45:25 UTC
In FreeBSD 13.0 release appeared new memory protection mechanism: W^X (write XOR execute) [0]. But unfortunately, some ports are still not adapted their code to be able to run in this mode. One of them is net-p2p/transmission-remote-gui, written in pascal language.

% transgui
exec_new_vmspace: mapping stack size 0x20000000 prot 0x7 failed mach error 2 errno 13
Abort

Workaround [1] with setting `elfctl -e +wxneeded` didn't help either.

Also wonder, what could possibly make this port incompatible with W^X?
Whether FreePascal does have some custom runtime routines that triggers it?
I thought it could be seen only with languages with JIT runtimes, like Java…


[0] https://cgit.freebsd.org/src/commit/?id=2e1c94aa1fd5
[1] https://forums.freebsd.org/threads/rclone-not-working-with-w-x.80279/
Comment 1 Jose Alonso Cardenas Marquez freebsd_committer 2021-07-31 19:34:22 UTC
(In reply to Andrey Korobkov from comment #0)

Hi, maybe the main reason could be fpc/lazarus use syscalls and if I'm not mistaken this kind of protection avoid this kind of procedures. But fpc/lazarus have a FPC_USE_LIBC option for use LIBC instead of direct syscalls. I don't know if it is well updated and maybe it could break somethings