You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I have an issue with the way the Console.CancelKeyPress event is implemented:
In my scenario I'm running a vanilla ASP.Net Core 2.2 web application. The web application internally adds a ctrl-c handler and gracefully shuts down the application when ctrl-c is pressed.
Now I had to add some logic to the application that's run in a Java VM via JNI. It seems that initializing JNI registers a SIGINT handler that throws away the console ctrl-c handler registered by ASP.Net.
Pressing ctrl-c when JNI is initialized immediately exits the process even leaving zombie processes behind on Linux.
In my scenario this means that after JNI init I can no longer use Console.CancelKeyPress because it will not re-register the handler and throw the JNI handler out.
I have a workaround for this issue but it depends on private reflection. It sets Console.s_registrar to null and registers a dummy ctrl-c handler in order to throw out the JNI handler. Naturally this approach can break any day when the implementation changes and so I'd appreciate any help in this matter.
Edit: Unfortunately the workaround above does not work on Linux. I've validated it on Windows with dotnet core 2.2.101.
Edit 2: I found that on Linux a workaround for this issue is to retrieve the current SIGINT handler before a problematic native call and restore if afterwards. E.g.:
#include<signal.h>// ...structsigaction oldAct = {0};
sigaction(SIGINT, nullptr, &oldAct);
// a third party call that changes the SIGINT handlerconstlong flag = JNI_CreateJavaVM(&vm, reinterpret_cast<void**>(&env), &vmArgs);
sigaction(SIGINT, &oldAct, nullptr);
The text was updated successfully, but these errors were encountered:
I am not familiar with JNI and I've one question: is it running within the same process or a different process on the same VM?
Hi Adam,
In the scenario I've described a JNI VM was created in-process via PInvoke. Initializing JNI is really just an example of any piece of (third party) native code replacing the ctrl-c handler which leaves Console.CancelKeyPress unable to continue working properly afterwards.
Hi,
I have an issue with the way the
Console.CancelKeyPress
event is implemented:In my scenario I'm running a vanilla ASP.Net Core 2.2 web application. The web application internally adds a ctrl-c handler and gracefully shuts down the application when ctrl-c is pressed.
Now I had to add some logic to the application that's run in a Java VM via JNI. It seems that initializing JNI registers a SIGINT handler that throws away the console ctrl-c handler registered by ASP.Net.
Pressing ctrl-c when JNI is initialized immediately exits the process even leaving zombie processes behind on Linux.
I looked into the implementation of
Console.CancelKeyPress
and found that it uses an internal helper type ConsolePal.ControlCHandlerRegistrar that's only registering a ctrl-c handler on the first usage of event addition. On subsequent event additions only the cancel callbacks are chained together.In my scenario this means that after JNI init I can no longer use
Console.CancelKeyPress
because it will not re-register the handler and throw the JNI handler out.I have a workaround for this issue but it depends on private reflection. It sets
Console.s_registrar
to null and registers a dummy ctrl-c handler in order to throw out the JNI handler. Naturally this approach can break any day when the implementation changes and so I'd appreciate any help in this matter.Thanks!
Edit: Unfortunately the workaround above does not work on Linux. I've validated it on Windows with dotnet core 2.2.101.
Edit 2: I found that on Linux a workaround for this issue is to retrieve the current
SIGINT
handler before a problematic native call and restore if afterwards. E.g.:The text was updated successfully, but these errors were encountered: