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

Ctrl-C cannot kill the Crystal compiler #13672

Closed
MistressRemilia opened this issue Jul 18, 2023 · 4 comments · Fixed by #13673
Closed

Ctrl-C cannot kill the Crystal compiler #13672

MistressRemilia opened this issue Jul 18, 2023 · 4 comments · Fixed by #13673
Labels
kind:bug kind:regression Something that used to correctly work but no longer works topic:stdlib:runtime
Milestone

Comments

@MistressRemilia
Copy link
Contributor

MistressRemilia commented Jul 18, 2023

Version 1.9.x of the compiler cannot be killed with Ctrl-C or by doing a kill -s INT. Ctrl-\ still works, and I've confirmed that Ctrl-C worked in 1.8.2.

A few of my own programs also exhibit this behavior, but I haven't been able to reduce it, and I have no idea where to even start with this one. Doing a Signal::INT.trap doesn't work, either.

Crystal -v output:

Crystal 1.9.1 [c355a34e5] (2023-07-17)

LLVM: 13.0.0
Default target: x86_64-unknown-linux-gnu

I also checked against the pre-built binaries:

Crystal 1.9.1 [c355a34e5] (2023-07-17)

LLVM: 15.0.7
Default target: x86_64-unknown-linux-gnu

OS: Slackware Linux 15.0, x86-64

@Sija
Copy link
Contributor

Sija commented Jul 18, 2023

True, killing spec runner stopped working.

@straight-shoota
Copy link
Member

This change must come from #13568

I think the interrupt still works, it just doesn't exit immediately. This can result in the process exiting normally before the interrupt handler excutes.

And I can see why: Before #13568, the signal was not trapped and thus would lead directly to exit the process without any involvement of the Crystal runtime.
Now we're trapping SIGINT and SIGTRAP for the handlers to call Crystal's exit routine. But the handler execution is decoupled from the trap. When it receives a signal, it writes it to a pipe and that pipe is then read from the Signal loop fiber which then executes the handler. During compilation the main fiber is occupied with calculations and offers no chance for the signal loop fiber to run.

It's probably best to revert #13568 and continue the discussion about how to best implement #8687.

@straight-shoota
Copy link
Member

@Sija I cannot reproduce with the spec runner. Usually the formatter regularly prints to STDOUT and this IO operation offers a chance for the scheduler to run the signal loop. Can you show a concrete example?

@straight-shoota straight-shoota added this to the 1.9.2 milestone Jul 18, 2023
@straight-shoota straight-shoota added kind:regression Something that used to correctly work but no longer works kind:bug topic:stdlib:runtime and removed kind:bug labels Jul 18, 2023
@hmood501

This comment was marked as spam.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:bug kind:regression Something that used to correctly work but no longer works topic:stdlib:runtime
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants