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

SIGILL signal or Illegal instruction message #513

Closed
kimjs29 opened this issue Jun 12, 2016 · 6 comments
Closed

SIGILL signal or Illegal instruction message #513

kimjs29 opened this issue Jun 12, 2016 · 6 comments

Comments

@kimjs29
Copy link

kimjs29 commented Jun 12, 2016

I want to catch SIGILL signal or receive "Illegal instruction" on stderr.

The following test code corrupts returning address on stack intensionally, which generates on Linux SIGILL signal on the executable stack or SIGSEGV signal on the non-executable stack, respectively.

void foo(int n) {
    long buf[] = {-1};
    buf[n] = (long)buf;
}

int main() {
    foo(3);
}

The executable stack can be set by using execstack -s command and verified by using readelf -l command.

On WSL the above code generates only SIGSEGV signal in both cases. I know mprotect(... PROT_GROWSDOWN) is not supported on WSL, but I think this case should be distinguished.

@kimjs29
Copy link
Author

kimjs29 commented Jun 19, 2016

I am testing Swift on WSL.

The test suite expects "Illegal instruction" error message in some test cases.

On WSL, the same errors as above display "Segmentation fault" or nothing.

@sunilmut
Copy link
Member

Thanks for reporting this. This is something we are aware of i.e WSL does not pass on all the exceptions today such as Illegal instruction, divide by zero, floating point exception etc. We have a task internally to track this, but, unfortunately something we won't be able to address for the Anniversary update. Please keep the feedback coming, we appreciate it!

@sunilmut
Copy link
Member

Just FYI that we have opened a bug internally to track this.

@Petermarcu
Copy link
Member

@sunilmut , any chance this was fixed internally? We're looking at getting all our tests passing again and this is one of the issues we're tracking on that.

@misenesi
Copy link

@Petermarcu it hasn't been yet tackled, but we are actively looking into supporting this, please be patient with us, as this involves some NT kernel changes.

@stehufntdev
Copy link
Collaborator

We submitted a fix to improve signal delivery around integer divide by zero and illegal instructions which should be in insider builds shortly.

For the repro in the original post, that will still generate SIGSEGV since the stack cannot currently be marked as executable on WSL. As mentioned in the original post, native Linux also generates SIGSEGV when the stack is not executable.

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

No branches or pull requests

7 participants