Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Partial workaround for use of win32_altstack_handler in inappropriate contexts #108

Merged

Conversation

embray
Copy link
Collaborator

@embray embray commented Feb 27, 2019

See https://trac.sagemath.org/ticket/27214#comment:11

One thing I might also add is in the case of STATUS_ACCESS_VIOLATION, one thing I can do at the very least is query the Windows VMM for the state of the accessed memory region. If it returns MAP_RESERVE there's a good chance we are hitting the still unhandled corner case I described in the comments, and can print an additional message with the hint about using mprotect(...). I'm not sure it really matters though.

@embray
Copy link
Collaborator Author

embray commented Feb 27, 2019

Need to add more documentation to the test.

@embray embray force-pushed the cygwin/altstack-handler-noreserve-bug branch from 4c9652f to 2fbb09a Compare February 27, 2019 14:58
@embray
Copy link
Collaborator Author

embray commented Feb 28, 2019

The failures on the Travis build don't appear to be relevant. It's failing like

    x86_64-conda_cos6-linux-gnu-gcc -pthread -DNDEBUG -fwrapv -O2 -Wall -I/home/travis/miniconda3/envs/test/include -fPIC -DCYTHON_CLINE_IN_TRACEBACK=0 -U_FORTIFY_SOURCE -Isrc/cysignals -Isrc -I/home/travis/miniconda3/envs/test/include/python3.6m -c build/src/cysignals/signals.c -o build/temp.linux-x86_64-3.6/build/src/cysignals/signals.o
    unable to execute 'x86_64-conda_cos6-linux-gnu-gcc': No such file or directory
    error: command 'x86_64-conda_cos6-linux-gnu-gcc' failed with exit status 1

@jdemeyer
Copy link
Collaborator

The failures on the Travis build don't appear to be relevant. It's failing like

This is supposed to be fixed by cfbd43b

Can you rebase to latest master?

@embray
Copy link
Collaborator Author

embray commented Feb 28, 2019

Oh, I remember seeing that commit but didn't understand what it was for. Yes, I'll try that.

https://trac.sagemath.org/ticket/27214#comment:11

Includes regression test.

As noted in the comment, this can still invoke undesired behavior in the
case where an unintialized region of an mmap created with MAP_NORESERVE
is accessed from within a signal handler.

At the time there is no good way to handle that case without extra
support from Cygwin's API which is currently not available as far as I
can tell.  A workaround, for the rare code where this might be
necessary, is to call mprotect (with the appropriate flags) on the
region of memory that needs to be accessed before attempting to access
it.
@embray embray force-pushed the cygwin/altstack-handler-noreserve-bug branch from 2fbb09a to 36e767f Compare February 28, 2019 11:29
@jdemeyer jdemeyer merged commit 36e767f into sagemath:master Mar 5, 2019
@embray embray deleted the cygwin/altstack-handler-noreserve-bug branch March 12, 2019 12:44
dimpase pushed a commit to sagemath/sagetrac-mirror that referenced this pull request Nov 9, 2020
handler

This is the fix from sagemath/cysignals#108
adapated to apply to cysignals v1.8.1.

This fix is needed to resolve Trac #27214.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants