Reputation: 760
I have an MSVC project, this project consists of multiple DLLs called from an executable. One of these DLLs initializes CEF (Chromium Embedded Framework) and another provides some other general functionality, We'll call them cefDLL and generalDLL. The calls go like this:
If I try to run the debugger on the crashed program I get a blank Visual Studio, no call stack, no locals, nothing, not even the name of a failed DLL.
If I call a function from another DLL, a function from the executable itself or none at all, the code reaches my infinite loop just fine (I'm using an infinite loop to stop the rest of the program from running).
If I let it keep running into the rest of the program and don't stop it with an infinite loop two more threads in CEF crash for a total of three crashed threads. These produce exactly the same errors as the first thread. I'm not sure what causes this precisely as I haven't had the time to look into this yet.
Even if the functions called in generalDLL do absolutely nothing this still occurs. I am certain it is the act of calling them that causes this, if my code is
initializeCEF();
while (true)
{
}
it works, if the code is
initializeCEF();
someBlankFunctionInGeneralDLL();
while (true)
{
}
the thread crashes.
The initialization of CEF consists of this:
//Initialize
CefMainArgs mainArgs;
//Launch Threads
CefExecuteProcess(mainArgs, nullptr, nullptr);
//Settings
CefSettings settings;
settings.pack_loading_disabled = true;
settings.windowless_rendering_enabled = true;
settings.multi_threaded_message_loop = false;
settings.no_sandbox = true;
//Sandbox Info
void *sandboxInfo = nullptr;
//Launch System
CefInitialize(mainArgs, settings, nullptr, sandboxInfo);
Does anyone have the faintest idea what this could be caused by? It's easily among the strangest bugs I've ever encountered. The project is giant at 50,000 lines or so and there aren't really any other relevant parts so I can't really provide any examples I'm afraid. Let me know if there's some code you think it would help to see though.
Upvotes: 0
Views: 3278
Reputation: 804
You know CEF is multi-process, right? Is it possible that your main application that is initializing CEF is not able to start multiple instances correctly, or is not passing the required command-line arguments to your CEF-containing DLL at startup? See this documentation about the structure of CEF applications: https://bitbucket.org/chromiumembedded/cef/wiki/Architecture#markdown-header-cef3
You can try starting CEF with the "--single-process" argument to force it to run single process (though shipping with this is very much not recommended because they don't test Chromium in this configuration - it is just for debugging). If you are not passing command line arguments to CEF that is probably the start of your problems. To do this, you can add a handler for OnBeforeCommandLineProcessing() in you CefApp derived class, as recommended by the creator of CEF here: http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=12928&p=25732&hilit=main_args#p25717 . The override would end up looking something like this:
void ServiceCenterApp::OnBeforeCommandLineProcessing(const CefString& process_type,
CefRefPtr<CefCommandLine> command_line) {
if(!command_line->HasSwitch("single-process")) {
command_line->AppendSwitch("single-process");
}
}
But I don't see you defining a CefApp derived class, that would be an argument to CefInitialize(). For example, the cefclient sample has this in their wWinMain():
// SimpleApp implements application-level callbacks. It will create the first
// browser instance in OnContextInitialized() after CEF has initialized.
CefRefPtr<SimpleApp> app(new SimpleApp);
followed by
// Initialize CEF.
CefInitialize(main_args, settings, app.get(), sandbox_info);
Where you tell CEF to use the derived App, where you would override whatever handlers you need to. You might want to start with the simple_app sample for a very basic override.
For the debugging issue, try attaching to all processes launched, assuming I'm incorrect and the multiple processes are launching correctly.
Upvotes: 1