View Issue Details

IDProjectCategoryView StatusLast Update
0002179NoesisGUIC# SDKpublic2021-11-23 11:00
ReporterDavidYawCSpeed Assigned Tohcpizzi  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.1.1 
Target Version3.1.2Fixed in Version3.1.2 
Summary0002179: WebBrowser interferes with external processes and application termination
DescriptionWhen the web browser component is loaded, it makes several other things not work.
- We handle Ctrl-C to do a clean shutdown: Console.CancelKeyPress += Console_CancelKeyPress, and the Console_CancelKeyPress() method triggers a clean shutdown. When the web browser is loaded, Ctrl-C kills the application immediately, bypassing the clean shutdown.
- We also handle kill signals to do a clean shutdown: AppDomain.CurrentDomain.ProcessExit += AppDomain_ProcessExit, and AppDomain_ProcessExit also triggers a clean shutdown. (AppDomain.CurrentDomain.ProcessExit is trigged on Windows by closing the Noesis console window, or on Linux with the `kill` or `killall` command line utilities.) When the web browser is loaded, `killall UIShell` kills the application immediately, bypassing the clean shutdown.
- We spawn various external processes, to do various tasks in the OS. We use the .Net `System.Diagnostics.Process` class to do this. We do process.Start() followed by process.WaitForExit(). The WaitForExit() call is never returning, which interferes with many things in our system.

We have traced these issues to `libcef.so`. If we remove that library, all three of these things start working again. Also, all of those things work initially, but then stop working once the web browser view is loaded.

These issues do not occur on Windows-x64. This appears to be an issue only on Linux. (Possibly only Linux-ARM64. I didn't test Linux-x64, so I don't know one way or the other.) This issue occurs with both WebBrowser 1.0.2 and 1.0.3.

My best guess as to what's going on: For Ctrl-C and `kill`, perhaps libcef.so is installing its own signal handler, and it needs to be changed to not do that? For the external process thing, I have no idea what the cause could be, but it's definitely that library.
Steps To ReproduceHere's my debugging code. Within a Linux-ARM64 application that loads the web browser, do this:

// Early at startup:
Console.CancelKeyPress += Console_CancelKeyPress;
AppDomain.CurrentDomain.ProcessExit += AppDomain_ProcessExit;

// At the end of startup:
RunExternalProcess("/bin/ls", "-l /"); // Get a long-format listing of the root dir.

private static void Console_CancelKeyPress(object sender, ConsoleCancelEventArgs e)
{
    logger.Warn("Ctrl-C received. Ignoring for testing purposes.");
    e.Cancel = true;
}

private static void AppDomain_ProcessExit(object sender, EventArgs e)
{
    // This method is triggered if you `kill` this task on Linux, or if you close the
    // console window on Windows. (And also if the process exits normally, of course.)

    // There's no way to "cancel" this. Our real code triggers an emergency shutdown, and 
    // then blocks here until the emergency shutdown is complete. For testing purposes, 
    // just print that we got this event, wait a bit, and then let the process exit happen.
    logger.Warn("AppDomain exiting.");
    Thread.Sleep(3000);
}

private static void RunExternalProcess(string executable, string arguments)
{
    using Process p = new Process();
    p.StartInfo.FileName = executable;
    p.StartInfo.Arguments = arguments;
    p.StartInfo.UseShellExecute = false;
    p.StartInfo.RedirectStandardOutput = true;
    p.StartInfo.RedirectStandardError = true;
    p.OutputDataReceived += dataReceived;
    p.ErrorDataReceived += dataReceived;

    p.Start();

    // This is necessary to make the event get triggered. No need to read the streams, 
    // the event will do the data recording we need.
    p.BeginOutputReadLine();
    p.BeginErrorReadLine();

    logger.Warn("Before WaitForExit: {0} {1}", executable, arguments);
    p.WaitForExit();
    logger.Warn("After WaitForExit: {0} {1}", executable, arguments);
}

- With libcef.so present, before the web browser view has loaded, Ctrl-C prints the expected log message, and the application doesn't exit. After the web browser view has loaded, Ctrl-C terminates the application without a message, `kill` terminates the application without a message, and all processes spawned don't return, including `ls -l`.
- With the exact same compile output, but libcef.so removed, after the web browser view has loaded, Ctrl-C prints the expected message and doesn't exit, `kill` prints the expected message, waits 3 seconds, then exists, and `ls -l` returns properly.

At the moment, the web browser is a smaller part of our application than spawning external processes is, so I have web browser disabled.
TagsNo tags attached.
PlatformLinux

Activities

sfernandez

sfernandez

2021-11-23 11:00

manager   ~0007601

Fixed in WebBrowser 1.0.4

Issue History

Date Modified Username Field Change
2021-11-05 20:25 DavidYawCSpeed New Issue
2021-11-05 20:29 DavidYawCSpeed Description Updated
2021-11-05 20:29 DavidYawCSpeed Steps to Reproduce Updated
2021-11-09 11:00 sfernandez Assigned To => hcpizzi
2021-11-09 11:00 sfernandez Status new => assigned
2021-11-09 11:00 sfernandez Target Version => 3.1.2
2021-11-23 11:00 sfernandez Status assigned => resolved
2021-11-23 11:00 sfernandez Resolution open => fixed
2021-11-23 11:00 sfernandez Fixed in Version => 3.1.2
2021-11-23 11:00 sfernandez Note Added: 0007601