-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debug build Hangs during Startup #12388
Comments
Comment by gruehle Low priority to |
Comment by redmunds I needed the Mac debugger last week and ran into this. It doesn't seem like "low priority" when you need it. :) Using git bisect, I isolated this problem to commit adobe/brackets-shell@fdea13a from pull request adobe/brackets-shell#281 by The code seems to go into an infinite loop. The menu works, but nothing happens when you select anything. Re-assigned to |
Comment by redmunds I cannot run a debug build on Windows either. Seems similar -- caught in an infinite loop. Looks like maybe a resource deadlock? Here's the callstack:
|
Comment by redmunds Bumping this up to Medium Priority. |
Comment by RaymondLim
Below is the call stack on Mac and I think it's more useful than the one ASSERTION FAILED: foundContainer |
Comment by RaymondLim Pull request adobe/brackets-shell#355 only fixes the specific issue on mac and still does not fix the other pre-existing issue that causes Brackets window going blank. |
Comment by RaymondLim
If you review the calll stack I pasted above, you will see that the crash (segmentation fault) is happening when rendering the editor. So I began suspecting that the crash was introduced in Brackets repo and not in Brackets-shell repo. And It took me several tries on brackets repo using "git bisect" and finally I found out that it is caused by So reassigning to |
Comment by peterflynn Interesting... |
Comment by RaymondLim
Oops... spoke too soon. I just got a crash after switching project, but definitely not that easy to crash w/o these CSS properties. Below is the call stack I got with this change. ASSERTION FAILED: m_verifier.isSafeToUse() |
Comment by njx That second crash looks like a v8 crash, so it might not be related to the renderer. |
Comment by redmunds Yay! I can run Debug builds on both Mac and Windows again! |
Comment by RaymondLim But you still can't change project with the dropdown. Otherwise, you will hit the second crash. |
Comment by redmunds I didn't test exhaustively, but I was able to switch to another project and then switch back to the first project. |
Comment by RaymondLim Ok, the second crash doesn't happen on every click. But occasionally it can happen when hovering, clicking and double-clicking on file/folder in the file tree or X button before file in working set or the project dropdown list. |
Comment by njx Not sure I'm the right person to look at this since I don't have much experience debugging in the shell. |
Comment by JeffryBooher I've not have any problems on OSX debugging although it is slower. The work-around that I suggest is to use the release binaries of CEF for building the debug version of the shell. That should get you past all of the assertions that seem to come up in the debug builds but crashers in the renderer may still occur in the release build of CEF. If it is a reproducible case then it's best to get that datapoint to Stefan-Teodor Craciun [email protected] and see if he can figure it out. Kind of hard to follow this thread but it sounds like this particular instance of the crash is in V8, so it will require someone with security access to V8 source in order to debug it or at least enough knowledge to know how to get it reported correctly to the V8 team. I'd start with running with the release binaries. If you can get past your crash with the release binaries then I don't think there is anything else we need to do about it. |
Comment by bchintx +1 to In addition to his workaround, on Windows, I'd also suggest just sandwiching any code that you want to debug with the following optimization-disabling switches:
Now, you can continue to build Release, be able to step thru the code quickly, but have non-mangled, full debug symbols for that section of code. |
Comment by ingorichter
|
Comment by redmunds
|
Comment by JeffryBooher
|
Comment by nethip I think it is the node connection that is causing this crash in debug builds. Commenting CC |
Issue by ingorichter
Friday Sep 20, 2013 at 16:43 GMT
Originally opened as adobe/brackets#5277
Original Title: Brackets debug build on OSX crashes during startup
Result: the app crashes.
Same result on Windows.
The text was updated successfully, but these errors were encountered: