Brackets crash after closing developer tools

[n1kkou]

Opening Developer Tools will crash the Brackets window, after closing the Developer Tools window.
Current configuration: Windows7 / 64bits operation system

[redmunds]

@n1kkou Can you provide a set a steps to reproduce problem? What error messages are you seeing and where?

[n1kkou]

@redmunds

1. Open a file in Brackets or just Launch Brackets(I tested to see if there's any difference between launch mode);
2. Debug -> Show Developers Tools;
3. The developers tools is opening, all fine, then close the developers tools window and it crashes the app;
   Screen attached:
   

P.S. I tried also to load Brakets without extensions but there's no difference, same issue.

[redmunds]

I am not seeing that on Win7 64-bit.

Which version of Chrome are you using? Brackets only officially supports current stable version, so be sure you try that.

What other Windows apps are you running? Can you try rebooting Windows and try again before opening any other apps?

[n1kkou]

Yes, you are right, the crash is caused by latest beta version of chrome "Version 38.0.2125.44 beta-m (64-bit)".
Sorry for the ticket! My bad, I forgot that I'm using a beta version on this PC :)

[redmunds]

Thanks for the followup so we can keep an eye on this version of chrome. Closing.

[n1kkou]

@redmunds Just tested it on another pc with Chrome stable Version 38.0.2125.24 m(fresh install), on windows 8 / 32 bits, and the problem persists.

[redmunds]

I find it difficult to figure out what the current version of stable chrome is. My chrome says "Version 37.0.2062.103 m", so I'm sure that you're not running stable. I think the "m" means beta channel, but I'm not sure.

To be sure, I think you need to remove all versions of chrome, and possibly clean up the registry.

[n1kkou]

I found this article where it says that the simple "m" at the end means the latest stable version: http://superuser.com/questions/339573/how-can-i-tell-which-google-chrome-channel-im-running (sorry if I'm not allowed to post this)

Here(on win8 / 32bits OS version) I installed this version for the first time(fresh windows install).

[redmunds]

Re-opening so someone with Win8 can try to reproduce this. @JeffryBooher ?

[marcelgerber]

I'm on Win8.1 and just updated to 37.0.2062.120 m (64-bit), which is definitely the latest version.
I also tried to repro the issue w/ Chrome Canary (39.0.2150.3 canary (64-bit)), but was unable to do so.

[peterflynn]

I can repro this on Windows 7 -- it's been happening to me for a long time, ever since our last CEF update IIRC. I thought I'd filed a bug about it a while back and it was sitting around low-priority somewhere (since it was UTR for most other people)... but I can't find that bug now so maybe I never actually got around to filing it.

The behavior I see is that closing dev tools causes Brackets to hang for a while (maybe 10-30 sec) after which it crashes.

I'm on Chrome 37.0.2062.103 m now, but given how long this has been going on I doubt it's specific to Chrome version.

[JeffryBooher]

Maybe this is a Windows 8 32 bit issue? I'm running Windows 8.1 64-bit.

[peterflynn]

Clarifying title

[peterflynn]

@JeffryBooher See above, I'm seeing this on Windows 7 (x64). So it's not specific to Win 8.

[JeffryBooher]

@peterflynn I guess I never see it on Windows 8.1 is because I run the CEF 1750 branch. Adding the CEF label.

[peterflynn]

I got a symbolized stack trace from my WIn 7 machine -- it does look like it's likely to be a CEF bug. It appears to be an NPE in the mini-HTTP server that is used to serve up the dev tools UI at localhost:9234:

ExceptionAddress: 1043405c (libcef!net::HttpServer::DidClose+0x0000008c)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 00000028
Attempt to read from address 00000028

...

STACK_TEXT:  
053bf5d4 0f7edec1 093e8a80 0f37b390 0287c320 libcef!net::HttpServer::DidClose+0x8c
053bf61c 0f37b3a7 000007ec 053bf94c 053bf644 libcef!net::StreamListenSocket::OnObjectSignaled+0x81
053bf62c 1097ebe4 093e8a80 053bf7d0 053bf94c libcef!base::win::ObjectWatcher::Signal+0x17
053bf644 0f37c055 0287c320 053bf94c 093e8c80 libcef!base::internal::Invoker<2,base::internal::BindState<base::internal::RunnableAdapter<void (__thiscall media::VideoDecodeAccelerator::Client::*)(int)>,void __cdecl(media::VideoDecodeAccelerator::Client *,int),void __cdecl(base::WeakPtr<media::VideoDecodeAccelerator::Client>,int)>,void __cdecl(media::VideoDecodeAccelerator::Client *,int)>::Run+0x34
053bf770 0f37e3fa 053bf7d0 02881930 75241400 libcef!base::MessageLoop::RunTask+0x295
053bf80c 0f3871ea 02881930 75241420 0f386d2e libcef!base::MessageLoop::DoWork+0x4ba
053bf818 0f386d2e 00000000 053bf94c 053bf94c libcef!base::MessagePumpForIO::DoRunLoop+0x7a
053bf838 0f37d53e 053bf94c 053bf910 75241420 libcef!base::MessagePumpWin::Run+0x3e
053bf900 0f384a53 0286e680 0f37b666 053bf94c libcef!base::MessageLoop::RunInternal+0x9e
053bf908 0f37b666 053bf94c 00000000 053bf910 libcef!base::RunLoop::Run+0x13
053bf92c 0faf177b 053bfa58 0faf1858 053bf94c libcef!base::MessageLoop::Run+0x16
053bf934 0faf1858 053bf94c 02810ad0 0286e680 libcef!base::Thread::Run+0xb
053bfa58 0f360388 00000000 00000000 02810ad0 libcef!base::Thread::ThreadMain+0xd8
053bfa6c 7524338a 000003b0 053bfab8 77629f72 libcef!base::`anonymous namespace'::ThreadFunc+0x58
053bfa78 77629f72 02810ad0 775ec298 00000000 kernel32!BaseThreadInitThunk+0xe
053bfab8 77629f45 0f360330 02810ad0 00000000 ntdll!__RtlUserThreadStart+0x70
053bfad0 00000000 0f360330 02810ad0 00000000 ntdll!_RtlUserThreadStart+0x1b

[marcelgerber]

I'm facing this issue now, too, while it worked perfectly well until 3 days ago.

[Chris2011]

Same problem here, here are my requirements:
Brackets: Latest version (1.0)
OS: Windows 7 x64
Chrome: Version 38.0.2125.111 m

[JeffryBooher]

BTW: This was not seen in CEF 1750 and so far not seen in 2171

[mesosteros]

I'm encountering this issue.
Brackets: Latest version (1.0)
OS: Windows 8.1 x64
Chrome: Version 38.0.2125.111 m

[compvid30]

Same problem here.

Brackets: Latest version (1.0)
OS: Windows 7 x64
Chrome: Version 39.0.2171.71 m

[BrantNielsen]

I unfortunately ended up losing a sizable portion of work today thanks to this bug, after I accidentally hit F12 instead of backspace. I've learned yet another hard lesson about how much I should be subconsciously saving things I guess...

This problem occurs probably about 4 out of 5 times I open up the developer tools.

Brackets: Release 1.0 build 1.0.0-15191
OS: Windows 8.1 x64
Chrome: Version 39.0.2171.71 m

[marcelgerber]

@KinoSuave The good news is, Brackets 1.1 will have an updated version of Chromium Embedded Framework (CEF), which seems to fix the issue. I haven't hit it since I started using the Brackets 1.1 Shell, while I hit it multiple times per day before.

[BrantNielsen]

@marcelgerber Thank heavens! Considering how long this has been an open issue, I wondered if I was going to have to get my F12 key removed.

[peterflynn]

@KinoSuave You can also always edit your keybindings to disable that shortcut.

[BrantNielsen]

@peterflynn Ah, I guess I didn't see editing those was a thing I could easily do. That's a great temp fix, thanks! Now I can stop keeping such a close eye on my fingers.

[marcelgerber]

I think we can close this now that we have CEF 2171. I haven't hit it a single time since updating to Brackets 1.1 Shell.
Or should we leave it open as long as the Linux users still have CEF 1547?

[peterflynn]

@marcelgerber Good point! I don't think this has ever been reported on any OS other than Windows, so it should be safe to close it.

[thrash646]

I now have this same issue on v1.5-1.7 of brackets.
Pretty sure it happened when I accidentally removed dev tools and then turned it back on.

I started a new thread here:
#12570