[CEF 2171] Crash on quit.

[RaymondLim]

Launch Brackets and press Ctrl+Q to quit. You will get a crash with the message saying "Brackets has stopped working."

Workaround: click on 'X' button in the title bar to quit.

[RaymondLim]

Below is the call stack from the release build

libcef.dll!521241f6()   
[Frames below may be incorrect and/or missing, no symbols loaded for libcef.dll]    
libcef.dll!51444e5c()   
libcef.dll!51444fab()   
libcef.dll!5143b667()   
libcef.dll!514dbf29()   
libcef.dll!5143ca90()   
libcef.dll!5143c61e()   
libcef.dll!5142853b()   
libcef.dll!514263d1()   
libcef.dll!513f2e67()   
ntdll.dll!_bsearch()  + 0x66 bytes  
Brackets.exe!CefCToCpp<CefV8ValueCToCpp,CefV8Value,_cef_v8value_t>::Release()  Line 79  C++
Brackets.exe!std::_Tree<std::_Tmap_traits<int,std::pair<CefRefPtr<CefV8Context>,CefRefPtr<CefV8Value> >,std::less<int>,std::allocator<std::pair<int const ,std::pair<CefRefPtr<CefV8Context>,CefRefPtr<CefV8Value> > > >,0> >::erase(std::_Tree_const_iterator<std::_Tree_val<std::_Tmap_traits<int,std::pair<CefRefPtr<CefV8Context>,CefRefPtr<CefV8Value> >,std::less<int>,std::allocator<std::pair<int const ,std::pair<CefRefPtr<CefV8Context>,CefRefPtr<CefV8Value> > > >,0> > > _First, std::_Tree_const_iterator<std::_Tree_val<std::_Tmap_traits<int,std::pair<CefRefPtr<CefV8Context>,CefRefPtr<CefV8Value> >,std::less<int>,std::allocator<std::pair<int const ,std::pair<CefRefPtr<CefV8Context>,CefRefPtr<CefV8Value> > > >,0> > > _Last)  Line 1382 + 0xb bytes    C++
Brackets.exe!ClientApp::`scalar deleting destructor'()  + 0x1c bytes    C++
Brackets.exe!ClientApp::Release()  Line 138 + 0x2e bytes    C++
Brackets.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow)  Line 277    C++
Brackets.exe!__tmainCRTStartup()  Line 275 + 0x1c bytes C
kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes    
ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes   
ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes    

[JeffryBooher]

@RaymondLim Does File > Exit crash as well?

[RaymondLim]

I didn't try it and now I'm back to master. But I did debug it yesterday and it is our exit command that is quitting immediately instead of waiting for JS callback's return. I believe message handling/routing changes in cef 1750 are causing this behavior.

[JeffryBooher]

I don't know much about the message handling/routing. I do know that the PreKeyEvent gets called twice for keys. One of those calls the os_event is NULL which caused a crash. Do you know of other such places in the code? I was unable to reproduce this.

Can you try to dSym the stack? The CEF functions are nameless.

[RaymondLim]

I was wrong in guessing the possible cause to message handling/routing changes in cef 1750. I debug it in the old cef and I got the same breakpoints and Brackets still quit without a crash. When I debug the issue with some more breakpoints in cef 1750 shell, I got the following call stack when it crashes, but the main thread seems to be still alive. So the crash seems to be in the helper thread (or JS side).

[RaymondLim]

After realizing the crash is in JS side, I used bisect to locate between sprint-36 and sprint-37. It turns out that it is my commit 4eee5ea that implements the new view states migration from the old pref. Apparently, the crash is the result of the shell code tearing down everything while the pref manager is still handling some fileIO by writing out some view states. @dangoor Can you suggest how we can return a promise from pref manager to the code that handles the quit command?

[dangoor]

@RaymondLim PreferencesBase.PreferencesSystem.save would seem to hold the key. I'm thinking that adding a _finalize method to PreferencesSystem might make sense. That would:

1. return the promise for the _nextSaveDeferred if there is one. If there isn't, return the promise for the current save operation (if there is one). If there isn't one of those, return a resolved promise.
2. set a flag that disallows any additional save operations. calls to save() after that point should either throw, reject the promise or just silently fail. I don't know what else happens on quit, so it's hard for me to say which is the best choice there. My guess is that rejecting the promise is likely the best choice.

How does that sound?