Error handling in CefRuntime.PostTask on Mono / macOS

Having problems with building or using the CefGlue .NET/Mono binding? Ask your questions here.

Moderator: fddima

Error handling in CefRuntime.PostTask on Mono / macOS

Postby weq » Wed Oct 14, 2020 12:16 am

Hello,

I am having an issues where tasks scheduled via posttask, if they throw, will crash the my process. Its extremely hard to debug these issues and im looking to tighten up my implementation and understand more of the mechanics at play here.

Ive tried try-catch statements around method blocks inside of the tasks, and they dont work... Is this a situation where CEF has just crashed my process for some reason and not the code that is throwing and thats why my try-catches dont work?

On a related note, is there guidance on getting the cef debug symbols going with cefglue? When these crashes happen, i sometimes i dont get much context at all. Sometimes CEF is really helpful, and gives me nice asserts or similiar that i can research. But other times, the stack is light on, and doesnt give much humean readable information. In these cases, I cant tell if its my code which is throwing or if its CEF killing me or what...? ive tried to use the debug_symbols by renamed to `libcef.dSYM` and placing in `frameworks` or `monobundle` and it doesnt give me any extra info in the stack at all...

Im currently debugging multiple issues with my App and have a sample implementation here.
https://github.com/captainjono/Chromely/issues/1

Right now ive just tried to integrate these fixes into my existing app, and when i call quitmessageloop() , its calling out to cef which is crashing the process I have no idea why. Verbose logging shows nothing. So im guessing...! would like a more structured approach!
Attachments
crash.png
crash on quitmessageloop()
crash.png (91.51 KiB) Viewed 1272 times
Last edited by weq on Sun Oct 18, 2020 9:17 pm, edited 1 time in total.
weq
Techie
 
Posts: 12
Joined: Mon Aug 10, 2020 8:23 pm

Re: Error handling in CefRuntime.PostTask

Postby fddima » Fri Oct 16, 2020 7:17 am

weq wrote:I am having an issues where tasks scheduled via posttask, if they throw, will crash the my process. Its extremely hard to debug these issues and im looking to tighten up my implementation and understand more of the mechanics at play here.

Ive tried try-catch statements around method blocks inside of the tasks, and they dont work... Is this a situation where CEF has just crashed my process for some reason and not the code that is throwing and thats why my try-catches dont work?

Try-Catches definitely work in any C# code. If you keep crashing - then issue somewhere in other place. CefGlue bindings almost never do try/catch internally, there is intended design choice to not hide exception(s) and let application crash: you anyway will somehow find a way to not raise exceptions and keep your application logic correct (because CEF/Chromium doesn't use exception, and so, throwing exception in any CEF-callback will destruct process state).
Also, with modern C# i'm recommend create some simple helper to posting tasks and handle their exceptions as you want.

On a related note, is there guidance on getting the cef debug symbols going with cefglue? When these crashes happen, i sometimes i dont get much context at all. Sometimes CEF is really helpful, and gives me nice asserts or similiar that i can research. But other times, the stack is light on, and doesnt give much humean readable information. In these cases, I cant tell if its my code which is throwing or if its CEF killing me or what...? ive tried to use the debug_symbols by renamed to `libcef.dSYM` and placing in `frameworks` or `monobundle` and it doesnt give me any extra info in the stack at all...

I'm not sure which OS you use. On windows you just put .pdb near your's executable (i guess there is exist bug, when they resolved not near libcef.dll but near .exe), on linux you have emebbded symbols in binaries, unless you doesn't strip them, so it should not require some any additional setup, and on macos i'm don't know.

Im currently debugging multiple issues with my App and have a sample implementation here.
https://github.com/captainjono/Chromely/issues/1

Right now ive just tried to integrate these fixes into my existing app, and when i call quitmessageloop() , its calling out to cef which is crashing the process I have no idea why. Verbose logging shows nothing. So im guessing...! would like a more structured approach!

Try start from simpliest possible application, and debug lifecycle. At the moment of CefRuntime.Shutdown() call there is no CEF objects should be lived (generally all browsers should be properly closed). CefRuntime.Shutdown() itself perform full GC, so if you don't keep references they will be released automatically. Unfortunately, there is no ultimate solution, because there is GC world and refcounting world fight one over other, and... well, even current CefGlue design is not a good. And on top of what nor GC nor refcounting did not protect from logical errors.

I would like to see any suggestions over API, if any exist.
fddima
Master
 
Posts: 788
Joined: Tue Dec 07, 2010 6:10 am

Re: Error handling in CefRuntime.PostTask

Postby weq » Sun Oct 18, 2020 9:10 pm

@fddima I appreciate the reply thanks! I wanted to know if there was a better way to be debugging this stuff...

ive been going through that fine grained process of elimination and i am making progress and coming across all those things u mentioned. Im attempting to build a working 2020 mono - xamarin.mac implementation of CefGlue via Chromely running on 83+ in multi-process and the threading model is really complex to wrangle on shutdown. I think my demo project is only working at the moment due to threading luck, and when i integrate it back into my other project its still failing to shut-down. I have extra complexity because im using an adapter in the middle to implement the proper macOS cefclient api. Tearing this down with the xam/mac/mono transition has been hard.

Im running on macos - so there is complexity in running libcef - if u checkout the main page of my repo i explain the process i went through and the edits i needed to make CefGlue happy on Xamarin.mac at runtime. To run the dSYM ur supposed to place next to libcef but i need to actually rename that framework on xam.mac to work with cefglue, so i dont really know if i am doing it right.

In other places i get line numbers, so i think this means though that i am doing it right?
crash2.PNG
crash2.PNG (118.9 KiB) Viewed 1182 times

I think the reason why i COULD NOT symbolise the original stack is because im not sure its actually even the OS knows what code it should be calling because the object could of been garbage collected and its nullreffing! I am progressing on my issues, but still not solved. Ive been able to translate some of those general exception codes by the OS into something that related vaguely to nullrefs, de-allocated pointers, and garbage collected callbacks. Im adding lots of logging too. This article https://docs.microsoft.com/en-us/xamari ... tive-crash has some good info that is applicable to any mono dev; the trick of running GC.Collect() in a loop on an external thread has helped make some of the errors i am getting MUCH more reproducable!

To others if they come accross this, here are some tips:

0. Cef References & C# references to CEFGlue components -- are different things! You want to release all CEFRefs on browser close otherwise shutdown will fail, but if you release to many C# references, GC can collect your references and break callbacks in CEF land that will crash your app. GC.Collect() on a loop can help.
1. if your try-catches are failing its because code is causing CEF to crash your app. Either because your throwing (in a CEF callback, posttask etc), or because you have violated CEFs API and its crashing you on purpose.
2. If u are debugging code always log with the threadIds so u know exactly where your code is being executed. Take note of the main-thread id.
weq
Techie
 
Posts: 12
Joined: Mon Aug 10, 2020 8:23 pm

Re: Error handling in CefRuntime.PostTask

Postby fddima » Tue Oct 20, 2020 11:51 am

weq wrote:@fddima I appreciate the reply thanks! I wanted to know if there was a better way to be debugging this stuff....


I'm understand possible complexity, but unfortunately can't really help, due miss of macOS experience (with stack traces). Does your stacktrace generated by mono? Does it at all lookup for native debug information? I just don't know.

As for disposing every wrapper is not really often necessary, but there is a good strategy to win. Actual issue what this is not currently automated and annoying, and not always clear. In the future i'm think what will resolve by making CefGlue API even more complexier, by adding thin stack-only wrappers, because over years i'm already recognized what 99.9% of wrappers (in CEF callbacks) actually never leave stack. But there is another story. In short i'm want to say, what dispose every wrapper which you no more need - is good idea.
fddima
Master
 
Posts: 788
Joined: Tue Dec 07, 2010 6:10 am


Return to CefGlue Forum

Who is online

Users browsing this forum: No registered users and 3 guests