Skip to content
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.

Crash in Brackets Sprint 30 #5132

Closed
dangoor opened this issue Sep 9, 2013 · 21 comments
Closed

Crash in Brackets Sprint 30 #5132

dangoor opened this issue Sep 9, 2013 · 21 comments

Comments

@dangoor
Copy link
Contributor

dangoor commented Sep 9, 2013

We've had two crash reports for Sprint 30. @cfjedimaster reported a crash (with no associated slowdown) while working on a file with unsaved data.

The crash log turned up a problem that arose in v8's parser.

@dangoor
Copy link
Contributor Author

dangoor commented Sep 9, 2013

Adding the "Mac only" label, because the two reports we had were both from Mac users.

@njx
Copy link
Contributor

njx commented Sep 9, 2013

Unfortunately I completely failed to write down the procedure I figured out for symbolizing a crash log like this, but it basically involved downloading the symbol file for the appropriate version of CEF, cutting the column of stack addresses out of the stack trace, and using atos to do the lookup. I can look at this later in the afternoon, but am blocked by meetings for most of the day.

@njx
Copy link
Contributor

njx commented Sep 9, 2013

Assigning to me for now.

@ghost ghost assigned njx Sep 9, 2013
@dangoor
Copy link
Contributor Author

dangoor commented Sep 9, 2013

I did write down the procedure for symbolizing a crash log. I'm in meetings until noon pacific, but I could steal this from you and symbolize the stack trace after that.

@njx
Copy link
Contributor

njx commented Sep 9, 2013

Looks like I'm free at 1 PT, so if you're free before that feel free to grab it, otherwise I can look at it then.

@dangoor
Copy link
Contributor Author

dangoor commented Sep 9, 2013

This appears to be a v8 bug. I'm hoping that we can find out if it's been fixed already. I'm going to mark this tracking for now, because I don't think there's anything we can do on our end just yet.

@Janpot
Copy link

Janpot commented Sep 9, 2013

@dangoor Like you asked on thread https://groups.google.com/forum/?fromgroups#!topic/brackets-dev/PHvGHgmKEvc here's my crash log, I also want to add that I've seen the same slowdown before with Ctrl-X on windows as well

(edited by @dangoor to move the crashlog elsewhere.)

This crash log shows an error in v8's incremental GC.

@dangoor
Copy link
Contributor Author

dangoor commented Sep 9, 2013

Thanks for the info @Janpot. Your crash appears to be in v8 also, but in a different place.

@pthiess
Copy link
Contributor

pthiess commented Sep 13, 2013

Adding recommendations from Niklas to get additional information. At this point I lower the priority as we don't see a high volume and we don't have repro steps.

  1. It would be useful if we can get a core dump for the crashing process.

On Mac OS X, add "limit core unlimited" to /etc/launchd.conf and reboot the machine.
Future crashes will produce core dumps in /cores/core.

  1. Additional useful information could come from V8 tracing. If it indeed is a bug in the V8 parser, it would be useful to know which piece of JS that triggered it.
    I am not familiar with how command line flags can be provided in CEF, but in Chromium --js-flags="--prof --log-timer-events" will enable fine-grained logging in v8 (ends up in v8.log).

@cfjedimaster
Copy link
Contributor

As just an FYI, I just had this happen again. This time while running Brackets from source, not a release build. I had literally just sat down to do some work, changed my project, turned on Live Connect, and typed some HTML when it went white. I'm going to do the limit action now and reboot.

Just noticed - I don't have /etc/launchd.conf.

@njx
Copy link
Contributor

njx commented Sep 14, 2013

@cfjedimaster - can you post your new crash log so we can verify it's the same crash? Thanks.

@nqn
Copy link

nqn commented Sep 16, 2013

@cfjedimaster sorry to hear you experienced the crash once more.

From the stack traces, it appears to be memory/GC issues. It would be extremely useful to get a core file for the crash.
If /etc/launchd.conf doesn't exist already, just go ahead and create it. It will work after a reboot.
Core files will be placed in /cores/< pid >.core
Note that core files can be fairly large (GB+), so you might want to disable it in the future.

We have reported the two incidents to the V8 developers and will follow up with any update on the issue.

@cfjedimaster
Copy link
Contributor

I've added it and will reboot soon.

On Mon, Sep 16, 2013 at 10:36 AM, Niklas Quarfot Nielsen <
notifications@github.com> wrote:

@cfjedimaster https://github.com/cfjedimaster sorry to hear you
experienced the crash once more.

From the stack traces, it appears to be memory/GC issues. It would be
extremely useful to get a core file for the crash.
If /etc/launchd.conf doesn't exist already, just go ahead and create it.
It will work after a reboot.
Core files will be placed in /cores/.core
Note that core files can be fairly large (GB+), so you might want to
disable it in the future.

We have reported the two incidents to the V8 developers and will follow up
with any update on the issue.


Reply to this email directly or view it on GitHubhttps://github.com//issues/5132#issuecomment-24519293
.

Raymond Camden, Adobe Developer Evangelist

Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: cfjedimaster

@njx
Copy link
Contributor

njx commented Sep 16, 2013

Hey--would still like to get your latest crash log (even if you don't have a core dump for it) so we can make sure it's the same crash. Thanks.

@cfjedimaster
Copy link
Contributor

Sorry - missed it:

https://dl.dropboxusercontent.com/u/88185/Brackets%20Helper_2013-09-14-090833_Raymonds-MacBook-Pro.crash

On Mon, Sep 16, 2013 at 5:16 PM, Narciso Jaramillo <notifications@github.com

wrote:

Hey--would still like to get your latest crash log (even if you don't have
a core dump for it) so we can make sure it's the same crash. Thanks.

Raymond Camden, Adobe Developer Evangelist

Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: cfjedimaster

@njx
Copy link
Contributor

njx commented Sep 17, 2013

@cfjedimaster - thanks for the new stack. Were you using the current shell from Sprint 31, or the one from Sprint 30?

@cfjedimaster
Copy link
Contributor

... I hate to say, I'm not 100% sure. I had switched to Sprint 31 a few
days ago, but after a reboot had loaded up 30. I can't honestly say what it
was at this time. Sorry!

On Tue, Sep 17, 2013 at 12:49 AM, Narciso Jaramillo <
notifications@github.com> wrote:

@cfjedimaster https://github.com/cfjedimaster - thanks for the new
stack. Were you using the current shell from Sprint 31, or the one from
Sprint 30?


Reply to this email directly or view it on GitHubhttps://github.com//issues/5132#issuecomment-24565473
.

Raymond Camden, Adobe Developer Evangelist

Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: cfjedimaster

@dangoor
Copy link
Contributor Author

dangoor commented Sep 24, 2013

I just encountered what I'm assuming is this crash for the first time. I haven't generated a stack trace for it yet, but here's the crash log

@nqn
Copy link

nqn commented Sep 24, 2013

FYI One of our reported issues (http://code.google.com/p/chromium/issues/detail?id=291020) was merged into http://code.google.com/p/chromium/issues/detail?id=291034 and has now been reported as fixed.

@njx
Copy link
Contributor

njx commented Jan 30, 2014

@dangoor Wonder if we can close this now - I don't think we've been hearing about a lot of crashes lately and it seems likely this was fixed in CEF.

@dangoor
Copy link
Contributor Author

dangoor commented Jan 30, 2014

Yes, I say we close this. I haven't been seeing new crash reports.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants