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

CEF3: Detect subprocess crashing #207

Closed
perlun opened this issue Nov 6, 2013 · 12 comments
Closed

CEF3: Detect subprocess crashing #207

perlun opened this issue Nov 6, 2013 · 12 comments

Comments

@perlun
Copy link
Member

perlun commented Nov 6, 2013

Right now, if the subprocess crashes early (on startup or similar), it is ignored and no error message is shown to the user. This is not so user friendly; we should really do something about it.

@cztomczak
Copy link

See the CefRequestHandler::OnRenderProcessTerminated():

  ///
  // Called on the browser process UI thread when the render process
  // terminates unexpectedly. |status| indicates how the process
  // terminated.
  ///
  /*--cef()--*/
  virtual void OnRenderProcessTerminated(CefRefPtr<CefBrowser> browser,
                                         TerminationStatus status) {}

In previous CEF versions this callback was in CefLoadHandler().

Though, this is only for the Renderer process. I don't know a way for other subprocesses.

@perlun
Copy link
Member Author

perlun commented Jan 31, 2014

Thanks! If I would just have some more time... 😄

Would you be willing to contribute (patches) to CefSharp3, btw? They would be highly appreciated; you seem to have a high level of knowledge regarding the CEF3 internals already.

@cztomczak
Copy link

@per I don't do programming in C#, though who knows, that might change. At the moment I am thinking on creating CEF bindings for the Go language. Although I already have lots of open tickets in cefpython (https://code.google.com/p/cefpython/issues/list), so I probably should take care of these first :)

@perlun
Copy link
Member Author

perlun commented Jan 31, 2014

😄 I think the real challenge is to find time to work on the open source stuff, when both work & AFK matters take a lot of your time and energy... + that you might not even want to do the "must" stuff when you finally have a spare moment. That's why CefSharp3 has been proceeding more slowly than I had first hoped. So, we would need all the extra "hands" we could get actually, but it's unfortunately harder to get people who submit code than to ask questions, for whatever reason... 😉

@cztomczak
Copy link

Yes, and the work :) I had a few patches sent by users, by that's only a drop in the bucket. Recently I spent a week working on an another OS project called PHP Desktop (https://code.google.com/p/phpdesktop/) and released a version with Chrome browser embedded. There are so many projects I would like to do :-) Who knows maybe I will try cefsharp too in some future. I've done once application in C#. But I abandoned it, I didn't like the garbage collector, it was causing a simple application to freeze for a few seconds.

@cztomczak
Copy link

A bit offtopic, but I have to. Regarding the garbage collector, I see that this is still kind of a major problem in .NET. Recently saw this talk about stackoverflow architecture: http://www.dev-metal.com/architecture-stackoverflow/ . In a nutshell: They don't use OOP, most of the code consists of static classes and static methods(!). The reason they don't use OOP and do no TDD, is because dot net GC (garbage collection) sucks. Instantiating classes will result in these classses being GC'ed later and that will hang their server for a few seconds. No OOP makes their code hard to test, so the GC is also responsible for not having unit tests.

That seems like a bad promotion of C# and .NET.

@perlun
Copy link
Member Author

perlun commented Jan 31, 2014

It sounds, yes. I wouldn't say that the GC has been a major problem for me (and I've done quite a bit of .NET coding during the last 5 years). More so in terms of memory leaks then, but the GC being slow has not really been an issue, ever.

Of course it depends on what you compare it with, but I so, so much prefer C# over more low-level languages (like C++); you get the job done much faster, with less lines of code, which equals less bugs.

For more dynamic, scripting-related stuff i use Ruby (quite a lot) and CoffeeScript (for client code that should run in a browser).

@jornh
Copy link
Contributor

jornh commented May 23, 2014

A bit more info on the topic: http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=11788 answering the question:
"what happens if user explicitly kills one of those processes using task manager? Will CEF find out the process termination and restart the process? "

Might be useful some day

@jornh
Copy link
Contributor

jornh commented May 31, 2014

@jothousand not that I know of. You are more than welcome to have a go at it.

Without having looked much at it I suspect it would be similar to #372.

@amaitland
Copy link
Member

@jothousand Any interest in contributing a PR to implement OnRenderProcessTerminated? I had a quick look at the Cef documentation, it's only slightly more complicated than implementing #372 OnPluginCrashed in that you have to add an enum to support TerminationStatus. It should still be very straight forward 😄

@amaitland
Copy link
Member

@jothousand Awesome!

I wrote some very rough notes about forking CefSharp, it might be of some help!
#362 (comment)

amaitland added a commit to amaitland/CefSharp that referenced this issue Jun 12, 2014
@jornh jornh modified the milestones: 31.0.1, 33.0.0 Jun 12, 2014
amaitland added a commit to amaitland/CefSharp that referenced this issue Jun 24, 2014
amaitland added a commit that referenced this issue Aug 5, 2014
Add OnRenderProcessTerminated - Resolves issue #207
@amaitland
Copy link
Member

Use IRequestHandler.OnRenderProcessTerminated to detect process termination.

Going to close this now as the PR resolving this was merged into master a while ago.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants