[Openmcl-devel] freshly built wx86cl64.exe crashes on start
bshetty at gmail.com
Thu Jan 5 00:33:58 PST 2023
Unfortunately yes in low memory for now. But as I pointed earlier there
might be issues with heap locations as well (windows handling FTH).
On Thu, Jan 5, 2023 at 5:27 AM R. Matthew Emerson <rme at acm.org> wrote:
> > On Jan 4, 2023, at 3:15 PM, Bharat Shetty <bshetty at gmail.com> wrote:
> > Since two days wx86cl64.exe has been behaving erratically (both the
> version i downloaded and built using gccv4.7.1) it has been crashing
> randomly at startup and emacs is unable to start it with slime. I suspect
> this might be to do with some security patches installed.
> > So I looked into the windows security controls. Turns out windows
> defender lets us configure "exploit protection setting" by configuring the
> following parameters
> > •
> > control flow guard CFG
> > • Data Execution Prevention DEP
> > • Mandatory ASLR (force randomisation for images - force relocation
> of images not compiled with Bottom-up ASLR ) -- off by default for now
> > • Randomise memory allocation (Bottom-up ASLR) -- on by default
> > • High Entropy ASLR - needs Bottom-up ASLR to be ON
> > • validate execution chains (SEHOP)
> > • validate heap integrity - terminate process when heap corruption
> os detected
> > I observed we can get wxcl8664 to run with 'Mandatory ASLR' and 'High
> Entropy ASLR' turned off and with all other options enabled. So even if gcc
> were to enable us to build non PIE position independant executable, it is
> just a matter of time before no-pie apps and ccl stops running on windows.
> > The only way we can keep ccl running is making the code relocatable
> (PIE) at the earliest. The bright spot is it still runs on linux :)
> The x86 port of CCL uses absolute addresses to reference code and other
> data in low memory. Is this what the problem is?
> Changing that would be a big hassle.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel