Crazy long stack trace

[DaveE]

We're embedding CEF in an app built upon the JUCE framework.
When debugging an unrelated issue, a breakpoint yielded a fairly hairy 2500+ call stack trace that was full of loops through CEF.

Is this a sign that we are doing something wrong, a symptom of a bigger issue, or just business as usual?

All of the stack trace (other than the very head and tail) was:

Code: Select all

--External Code--
libcef.dll!base::MessagePumpForUI::ProcessMessageHelper(const tagMSG & msg) Line 363   C++
libcef.dll!base::MessagePumpForUI::ProcessPumpReplacementMessage() Line 407   C++
libcef.dll!base::MessagePumpForUI::ProcessMessageHelper(const tagMSG & msg) Line 360   C++
libcef.dll!base::MessagePumpForUI::DoRunLoop() Line 198   C++
libcef.dll!base::MessagePumpWin::Run(base::MessagePump::Delegate * delegate) Line 58   C++
libcef.dll!base::MessageLoop::Run(bool application_tasks_allowed) Line 352   C++
libcef.dll!base::RunLoop::Run() Line 133   C++
libcef.dll!base::RunLoop::RunUntilIdle() Line 143   C++
libcef.dll!CefBrowserMessageLoop::DoMessageLoopIteration() Line 117   C++
libcef.dll!CefDoMessageLoopWork() Line 274   C++
Loopcloud.exe!CefDoMessageLoopWork() Line 397   C++
Loopcloud.exe!jcf::LcCefShared::timerCallback() Line 56   C++
Loopcloud.exe!juce::Timer::TimerThread::callTimers() Line 122   C++
Loopcloud.exe!juce::Timer::TimerThread::CallTimersMessage::messageCallback() Line 187   C++
Loopcloud.exe!juce::WindowsMessageHelpers::dispatchMessageFromLParam(long lParam) Line 55   C++
Loopcloud.exe!juce::WindowsMessageHelpers::messageWndProc(HWND__ * h, const unsigned int message, const unsigned int wParam, const long lParam) Line 100   C++
--External Code--
libcef.dll!base::MessagePumpForUI::ProcessMessageHelper(const tagMSG & msg) Line 363   C++
libcef.dll!base::MessagePumpForUI::DoRunLoop() Line 198   C++
libcef.dll!base::MessagePumpWin::Run(base::MessagePump::Delegate * delegate) Line 58   C++
libcef.dll!base::MessageLoop::Run(bool application_tasks_allowed) Line 352   C++
libcef.dll!base::RunLoop::Run() Line 133   C++
libcef.dll!base::RunLoop::RunUntilIdle() Line 143   C++
libcef.dll!CefBrowserMessageLoop::DoMessageLoopIteration() Line 117   C++
libcef.dll!CefDoMessageLoopWork() Line 274   C++
Loopcloud.exe!CefDoMessageLoopWork() Line 397   C++
Loopcloud.exe!jcf::LcCefShared::timerCallback() Line 56   C++
Loopcloud.exe!juce::Timer::TimerThread::callTimers() Line 122   C++
Loopcloud.exe!juce::Timer::TimerThread::CallTimersMessage::messageCallback() Line 187   C++
Loopcloud.exe!juce::WindowsMessageHelpers::dispatchMessageFromLParam(long lParam) Line 55   C++
Loopcloud.exe!juce::WindowsMessageHelpers::messageWndProc(HWND__ * h, const unsigned int message, const unsigned int wParam, const long lParam) Line 100   C++
--External Code--

In all, 158 calls to libcef.dll!CefDoMessageLoopWork() in the stack.

Other, perhaps useful info:

• CEF and the application were still working fine at this point, though the debugger wasn't coping well.
• I've only ever seen it get that bad once, Most (almost all) of the time, the stack trace is only one call into the CefDoMessageLoopWork.
• We are aiming to call CefDoMessageLoopWork every 20ms.
• It seems to get a little worse when the app is busy or interrupted (e.g. by a breakpoint)
• This is using 04/13/2018 - CEF 3.3325.1757.gdf2fcc8 / Chromium 65.0.3325.181 (debug dll)

Thanks,
Dave

[magreenblatt]

You should probably allow the stack to unwind before calling CefDoMessageLoopWork additional times.

[DaveE]

Thanks,
I've wrapped the call to CefDoMessageLoopWork in something like the below and it all still seems to still be working as intended whilst limiting the depth.

Code: Select all

int inMsgLoopCounter{0};
void timerCallback () override
{
    if (inMsgLoopCounter < 5)
    {
        inMsgLoopCounter++;
        CefDoMessageLoopWork();
        inMsgLoopCounter--;
    }
}


It's worth noting that, without that code, we can recreate the issue of repeated CefDoMessageLoopWork calls by having if another item constantly repainting.
Whilst I doubt it's graphical, it does seem like there is some kind of timing issue in play where, when the app is busy, tasks are being queued faster than they are dealt with.

We don't see this if CEF isn't running. Let me know if you would like more information.

Thanks,
Dave