Skip to content
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.

Sign up for GitHub

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

Jump to bottom

使用gdb调试v8 #2

Open
zhuzhuaicoding opened this issue Apr 12, 2017 · 0 comments
Open

使用gdb调试v8 #2

zhuzhuaicoding opened this issue Apr 12, 2017 · 0 comments

Comments

@zhuzhuaicoding
Copy link
Owner

zhuzhuaicoding commented Apr 12, 2017 •
edited
Loading

https://medium.com/@fhinkel/debug-v8-in-node-js-core-with-gdb-cc753f1f32#.1rpt67eg1
@zhuzhuaicoding zhuzhuaicoding changed the title 使用gdb调试v 使用gdb调试v8 Apr 12, 2017
zhuzhuaicoding pushed a commit that referenced this issue May 5, 2017
@mi-ac
Revert of [builtins] DeleteProperty: Handle last-added fast propertie…
852a20b 
…s (patchset #2 id:20001 of https://codereview.chromium.org/2830093002/ )

Reason for revert:
Breaks:
https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/12920
and
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/10281

Original issue's description:
> [builtins] DeleteProperty: Handle last-added fast properties
>
> In general, deleting a property from a fast-properties object
> requires transitioning the object to dictionary mode. However,
> when the most-recently-added property is deleted, we can simply
> roll back the last map transition that the object went through.
>
> This is a performance experiment: it should make things faster,
> but if it turns out to have more negative than positive impact,
> we will have to revert it.
>
> TBR=bmeurer@chromium.org (just adding a comment)
>
> Review-Url: https://codereview.chromium.org/2830093002
> Cr-Commit-Position: refs/heads/master@{#44799}
> Committed: https://chromium.googlesource.com/v8/v8/+/98acfb36e1acf2ab52ab6b6439eb6356c83dcda6

TBR=ishell@chromium.org,jkummerow@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review-Url: https://codereview.chromium.org/2843473002
Cr-Commit-Position: refs/heads/master@{#44806}
zhuzhuaicoding pushed a commit that referenced this issue May 5, 2017
@natorion
Revert of [snapshot] full setup delegate should also be able to deser…
6d9ca97 
…ialize. (patchset #2 id:20001 of https://codereview.chromium.org/2840493002/ )

Reason for revert:
prime suspect for https://bugs.chromium.org/p/chromium/issues/detail?id=714976

Original issue's description:
> [snapshot] full setup delegate should also be able to deserialize.
>
> Also move the responsibility of marking builtins as initialized
> to the deserializer.
>
> R=jkummerow@chromium.org
>
> Review-Url: https://codereview.chromium.org/2840493002
> Cr-Commit-Position: refs/heads/master@{#44802}
> Committed: https://chromium.googlesource.com/v8/v8/+/a2b3a2fbc562584ec298dfe674c97662a125a59e

TBR=jkummerow@chromium.org,yangguo@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.

BUG=chromium:714976

Review-Url: https://codereview.chromium.org/2841993002
Cr-Commit-Position: refs/heads/master@{#44870}
zhuzhuaicoding pushed a commit that referenced this issue May 5, 2017
@alexkozy
[inspector] better stacks for promises
f2bd913 
- we should always set creation async stack if it's available regardless existing of current parent async stack,
- we should cleanup parent link iff there is no creation and schedule async stack for parent.

Let's consider example: Promise.resolve().then(x => x).then(x => x), there is three promises which will call following instrumentation:
1) created #1 (Promise.resolve()) - collected stack #1
2) scheduled #1 - collected stack #2
3) created #2 with #1 as parent (first .then) - collected stack #3
4) created #3 with #2 as parent (first .then) - collected stack #4
5) started #2 - use stack #2 as scheduled
6) scheduled #2 - collected stack v8#6
7) finished #2
8) started #3 - use stack v8#6 as scheduled
9) scheduled #3 - collected stack v8#7
10) finished #3

If we collect stacks between step 4 and 5, it's possible to collect scheduled stack #2 but still have creation stack for #2 - stack #3 - so we always need to add creation event if scheduled is collected.

If we collect stacks between created and scheduled we should not remove parent link even if parent was not scheduled yet.

BUG=v8:6189
R=dgozman@chromium.org

Review-Url: https://codereview.chromium.org/2844753002
Cr-Commit-Position: refs/heads/master@{#44990}
zhuzhuaicoding pushed a commit that referenced this issue May 23, 2017
@ulan
Revert of [heap] Reland "Make non-atomic markbit operations consisten…
b7b3781 
…t with atomic ones." (patchset #2 id:20001 of https://codereview.chromium.org/2860323003/ )

Reason for revert:
box2d failures on buildbot

Original issue's description:
> [heap] Reland "Make non-atomic markbit operations consistent with atomic ones."
>
> Now non-atomic color transition operations return a boolean indicating
> whether the transition succeeded or not.
>
> This allows to replace color check and transition operations with a
> single transition operation. For example:
>
> if (IsWhite(object)) {
>   WhiteToBlack(object);
>   Foo();
> }
>
> becomes
>
> if (WhiteToBlack(object)) {
>   Foo();
> }
>
> BUG=chromium:694255
>
> CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
>
> Review-Url: https://codereview.chromium.org/2860323003
> Cr-Commit-Position: refs/heads/master@{#45123}
> Committed: https://chromium.googlesource.com/v8/v8/+/c0a65cd295301f334e2bbfcce46a937cd708beec

TBR=mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:694255

Review-Url: https://codereview.chromium.org/2863953002
Cr-Commit-Position: refs/heads/master@{#45127}
zhuzhuaicoding pushed a commit that referenced this issue May 23, 2017
@alexkozy
Revert of [inspector] use creation stack trace as parent for async ca…
fe0d5c7 
…ll chains (patchset #2 id:20001 of https://codereview.chromium.org/2868493002/ )

Reason for revert:
CHECK is too strict.

Original issue's description:
> [inspector] use creation stack trace as parent for async call chains
>
> Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved.
> For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same.
>
> BUG=v8:6189
> R=dgozman@chromium.org
>
> Review-Url: https://codereview.chromium.org/2868493002
> Cr-Commit-Position: refs/heads/master@{#45198}
> Committed: https://chromium.googlesource.com/v8/v8/+/e118462f18a862df81a04486e13dd62997cbfc5a

TBR=dgozman@chromium.org,alexclarke@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:6189

Review-Url: https://codereview.chromium.org/2868423004
Cr-Commit-Position: refs/heads/master@{#45242}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@zhuzhuaicoding