[Core][Win8 x86 OS only]: Brackets will crash if reload Brackets after cancelling the extension updating.

[julieyuan]

Steps:

1. Launch Brackets.
2. Click Extension Manager icon on the top right.
3. Install one extension into Brackets.
4. Install the same extension again.
5. Click Overwrite button on the Install Extension dialog.
6. Click Undo which is behind the string Marked for Update.
7. Click Close button on the Extension Manager dialog.
8. Click Debug > Reload Brackets.

Results:
The Brackets will crash and pop up the crash dialog.

Expected:
It should be reloaded successfully.

ENV: Win8 x86 ENU. Not reproduce in Win7 OS, Win8x64 or MAC.
Build: 0.27.0.8201

Comments:
Here is the error log in crash dialog to offer more info.
Problem signature:
Problem Event Name: APPCRASH
Application Name: Brackets.exe
Application Version: 0.27.0.0
Application Timestamp: 51c6bbea
Fault Module Name: libcef.dll
Fault Module Version: 3.1453.1255.0
Fault Module Timestamp: 518b812f
Exception Code: c0000005
Exception Offset: 011054db
OS Version: 6.2.9200.2.0.0.256.4
Locale ID: 1033
Additional Information 1: 55bd
Additional Information 2: 55bdb125e5f5eebba32ff4470f6d6db1
Additional Information 3: d8e7
Additional Information 4: d8e728cfa3b4627b86f2920172200c49

Please refer to screenshot for details:

[JeffryBooher]

So it turns out that it is a timing issue with tearing down the app. Here is the thread that crashes call stack:

libcef.dll!net::HttpServer::DidClose(net::StreamListenSocket * socket)  Line 144    C++
libcef.dll!net::StreamListenSocket::OnObjectSignaled(void * object)  Line 258 + 0x13 bytes  C++
libcef.dll!base::win::ObjectWatcher::Signal(base::win::ObjectWatcher::Delegate * delegate)  Line 101 + 0xb bytes    C++
libcef.dll!base::internal::Invoker<2,base::internal::BindState<base::internal::RunnableAdapter<void (__thiscall ppapi::ResourceTracker::*)(int)>,void __cdecl(ppapi::ResourceTracker *,int),void __cdecl(base::WeakPtr<ppapi::ResourceTracker>,int)>,void __cdecl(ppapi::ResourceTracker *,int)>::Run(base::internal::BindStateBase * base)  Line 1257 + 0x2b bytes C++
libcef.dll!MessageLoop::RunTask(const base::PendingTask & pending_task)  Line 478   C++
libcef.dll!MessageLoop::DoWork()  Line 672  C++
libcef.dll!base::MessagePumpForIO::DoRunLoop()  Line 523 + 0xc bytes    C++
libcef.dll!base::MessagePumpWin::Run(base::MessagePump::Delegate * delegate)  Line 48 + 0x3e bytes  C++
libcef.dll!MessageLoop::RunInternal()  Line 433 + 0xa bytes C++
libcef.dll!base::RunLoop::Run()  Line 46    C++
libcef.dll!MessageLoop::Run()  Line 314 C++
libcef.dll!base::Thread::Run(MessageLoop * message_loop)  Line 153  C++
libcef.dll!base::Thread::ThreadMain()  Line 201 C++
libcef.dll!base::`anonymous namespace'::ThreadFunc(void * params)  Line 58  C++
kernel32.dll!7539173e()     
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]  
ntdll.dll!76f96911()    
ntdll.dll!76f968bd()    

Here is the main thread's callstack:

ntdll.dll!76f57174()    
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] 
ntdll.dll!76f557ce()    
ntdll.dll!76f79562()    
Brackets.exe!_unlock(int locknum)  Line 375 C
Brackets.exe!_unlockexit()  Line 785 + 0x7 bytes    C
Brackets.exe!_onexit(int (void)* func)  Line 90 + 0x5 bytes C
Brackets.exe!atexit(void (void)* func)  Line 162 + 0x8 bytes    C
8bc30000()  

I'm not sure why atexit() is being called:

[JeffryBooher]

Tracking this issue as it is a CEF bug and may have existed in previous versions of Brackets/CEF. Reducing priority to medium

[JeffryBooher]

This seems like it's higher priority now since it's been reported in another scenario. We should probably call on the CEF team to help us out even though this was not reproducible in the reference app.

Marking this one "needs review" so we can discuss it with the ARB

[JeffryBooher]

There is another scenario that needs to be checked here:
Issue #4365

[JeffryBooher]

Making this high priority since we're tracking other scenarios

[JeffryBooher]

This one is related to #4522. If I don't have any files open then Brackets will not crash. Continuing to investigate separately until we have a stack trace for the crash on the Mac but it's starting to feel like those two are the same crash.

[njx]

Not sure they're related...this one doesn't require dev tools to be open, whereas #4522 does.

[njx]

(at least as far as I can tell...I can't repro it on Mac with dev tools closed.)

[JeffryBooher]

@njx does 4522 still crash without open any files open?

[njx]

No, and it seems sensitive to the type of file that's open. I'll add more comments there.

[JeffryBooher]

@julieyuan can you confirm that using the next nightly build and having devtools open when changing languages does not crash. We're trying to narrow this one down and it looks like leaving devtools open with the changes from adobe/brackets-shell#282 fixes the issue. We're working with the CEF team and Adobe to try to figure out why but it would help us if you could confirm it.

[julieyuan]

@JeffryBooher , I checked it in latest build 0.28.0.8470, on win8x86 English OS. If I let devtools open and switch between different languages, brackets doesn't crash. but if the devtools doesn't open,and then I switch languages from Chinese to English, Bracktes will crash. Here is the snapshot for changing languages with devtools opening:

[JeffryBooher]

Bumping the priority down on this and removing the milestone. It seems that it only crashes on Windows 8 32 bit and it's something in CEF that is crashing. We have an issue open with the CEF team to isolate the cause of the crash but it's not reproducible with the reference app.

Also leaving dev tools open avoids the crash.

[JeffryBooher]

Additional Notes to maintain concurrency:

The CEF Team has been investigating this and filed an issue with the chromium project:
https://code.google.com/p/chromium/issues/detail?id=263730

And submitted a patch to fix it.
https://codereview.chromium.org/20086002/diff/1/net/server/http_server.cc

The patch will most likely be rejected but it does serve as a spring board to get the discussion going. It looks like the issue has gotten some traction by a couple of chromium contributors.

[JeffryBooher]

@julieyuan can you reproduce it with Sprint 30? We introduced a new CEF that fixed quite a number of crashers so hopefully this is one of them.

[julieyuan]

Hi @JeffryBooher , I checked this issue with Sprint 31(0.31.0-9351). This issue not reproduces. But the related issue #4365 still happening. Should I close this one and reopen #4365? Or I just keep this one open to track this kind staff?

[JeffryBooher]

@julieyuan that's fine. Close this one and reopen #4365

[julieyuan]

Ok. Thanks. Closing it.