Add stacktrace dump and better error messages on EXC_BAD_ACCESS panics by lggomez · Pull Request #2904 · microsoft/vscode-go

lggomez · 2019-11-14T01:36:09Z

Fixes #1903

lggomez · 2019-11-14T01:37:57Z

@ramya-rao-a PTAL

lggomez · 2019-11-14T01:38:33Z

cc @jhendrixMSFT

ramya-rao-a · 2019-12-05T22:25:43Z

@jhendrixMSFT Can you take another look here?

jhendrixMSFT · 2019-12-06T18:27:53Z

+		// Get current goroutine
+		// Debugger may be stopped at this point but we still can (and need) to obtain state and stacktrace
+		let goroutineId = 0;
+		this.delve.call<DebuggerState | CommandOut>('State', [{ NonBlocking: true }], (err, out) => {


I tested this out on macOS, unfortunately dlv doesn't report the correct go routine in this case (I see the same behavior using vscode and dlv) so I think we can remove this. What it means though is if the panic is on a go routine other than zero you won't get the correct stack trace. If we still want to include the stack trace then I think we should add a message indicating that it might not be correct. :(

I would leave it just for diagnose purposes with a warning message saying that the stacktrace might differ from the expected goroutine

I tested this out on macOS, unfortunately dlv doesn't report the correct go routine in this case (I see the same behavior using vscode and dlv)

This is probably related to the original dlv issue, or maybe it is a different issue that might be actionable, nevertheless, that is still something that should be discussed upstream, unfortunately

lggomez · 2019-12-16T23:57:35Z

+			logError(message + ' - ' + errorMessage);
+
+			if (err.toString() === 'bad access') {
+				logError('WARNING: this stack might not be from the expected active goroutine');


I think this might suffice for now, what do you think @jhendrixMSFT?

I would reword this to "...the faulting goroutine".
I also wonder if it would just be better to omit the stack trace entirely given that it might not be accurate (we could add it later if there's sufficient feedback). @ramya-rao-a do you have an opinion about this?

ramya-rao-a · 2019-12-17T04:32:24Z

+
+			logError(message + ' - ' + errorMessage);
+
+			if (err.toString() === 'bad access') {


The same if check exists a few lines above, so consider moving this log statement to the previous if block

I don't like the duplicate if either but I did it so the warning comes right before the stacktrace and not before the errorMessage:

Current:

Simplified:

I don't think it is that much of an issue so if you're fine with that I can go on with the single if version

Understood, in that case let's keep the current order

ramya-rao-a · 2019-12-19T18:35:08Z

+		});
+
+		// Get goroutine stacktrace
+		const stackTraceIn = { id: goroutineId, depth: this.delve.stackTraceDepth };


The goroutineId here will always be 0 as this code path is not inside the callback provided to the delve call a few lines above.

You can try

try { const stateCallResult: DebuggerState | CommandOut = await this.delve.callPromise('State', [{ NonBlocking: true }]); goroutineId = this.delve.isApiV1 ? (<CommandOut>stateCallResult).State.currentGoroutine.id : (<DebuggerState>stateCallResult).currentGoroutine.id; } catch (error) { // log error? }

@jhendrixMSFT @ramya-rao-a I think I solved the issue of state returning always (?) zero. The gist of the debugger state is that there seems to be no currentGoroutine in this scenario so we have to default to the currentThread goroutineId:

This is the apicall response:

{ "Running": false, "currentThread": { "id": 5142829, "pc": 17138024, "file": "/Users/lgomez/DEV/go/test_1903/main.go", "line": 5, "function": { "name": "main.oops", "value": 17138000, "type": 0, "goType": 0, "optimized": false }, "goroutineID": 1, "ReturnValues": null }, "Threads": [ { "id": 5142829, "pc": 17138024, "file": "/Users/lgomez/DEV/go/test_1903/main.go", "line": 5, "function": { "name": "main.oops", "value": 17138000, "type": 0, "goType": 0, "optimized": false }, "goroutineID": 1, "ReturnValues": null }, { "id": 5142873, "pc": 140734907268914, "file": "", "line": 0, "goroutineID": 0, "ReturnValues": null }, { "id": 5142874, "pc": 140734907267178, "file": "", "line": 0, "goroutineID": 0, "ReturnValues": null }, { "id": 5142875, "pc": 140734907267178, "file": "", "line": 0, "goroutineID": 0, "ReturnValues": null }, { "id": 5142876, "pc": 140734907267178, "file": "", "line": 0, "goroutineID": 0, "ReturnValues": null } ], "NextInProgress": false, "exited": false, "exitStatus": 0, "When": "" }

And this is the handled panic with the updated behavior:

This is on mac, I´ll try this at home later to see if the response is different on linux

I'm not getting the currentGoroutine on linux either, i'm trying other goroutine examples and i'm even reproducing #2563 while at it so I'm willing to say this is our best bet for now. We're supposed to be getting this field but we can follow up on that issue since it is better suited for its root cause

ramya-rao-a · 2019-12-19T19:16:44Z

cc @quoctruong to try out the changes here

jhendrixMSFT · 2020-01-17T23:06:00Z

@ramya-rao-a any other concerns?

Usability workaround for microsoft#1903

lggomezml · 2020-02-17T03:47:15Z

@andrewchoi5 I decided to reset and rebase my changes to current master since there were many merge conflicts to solve (the branch was a bit stale and several changes entered into the debug adapter), would you care to check again please?

* master: goLanguageServer: set completion follow up command from middleware (microsoft#3084) Add stacktrace dump and better error messages on EXC_BAD_ACCESS panics (microsoft#2904) Address mismatch on path separators in debug config (microsoft#2010) (microsoft#3108) Include the link to release note/package overview in the update prompt, and update gopls default version (microsoft#3041) bug_report.md: Fix "architecture" typo. (microsoft#3095) telemetry.ts: send telemetry only if aiKey is not an empty string(microsoft#3091)

…sync microsoft/vscode-go@d53b1b3 * 'master' of https://github.com/microsoft/vscode-go: goLanguageServer: set completion follow up command from middleware (microsoft#3084) Add stacktrace dump and better error messages on EXC_BAD_ACCESS panics (microsoft#2904) Address mismatch on path separators in debug config (microsoft#2010) (microsoft#3108)

Merge branch 'master' of https://github.com/microsoft/vscode-go@d53b1b3 * 'master' of https://github.com/microsoft/vscode-go: goLanguageServer: set completion follow up command from middleware (microsoft#3084) Add stacktrace dump and better error messages on EXC_BAD_ACCESS panics (microsoft#2904) Address mismatch on path separators in debug config (microsoft#2010) (microsoft#3108) Created by `git pull --no-ff --log upstream master` Change-Id: Id38768f3ec1bd01fa81325978f51f314fc1c08cb GitHub-Last-Rev: 3a8de3f GitHub-Pull-Request: #17 Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/224240 Reviewed-by: Rebecca Stambler <rstambler@golang.org>

lggomez added 4 commits April 21, 2019 15:00

Merge remote-tracking branch 'upstream/master'

c249f49

Merge remote-tracking branch 'origin/master'

7501734

Merge remote-tracking branch 'upstream/master'

fe2cb47

Merge branch 'master' of https://github.com/Microsoft/vscode-go

9359e1c

lggomez force-pushed the fix_1903 branch from 9198d52 to 0884de1 Compare November 14, 2019 03:38

jhendrixMSFT reviewed Nov 14, 2019

View reviewed changes

Comment thread src/debugAdapter/goDebug.ts Outdated

jhendrixMSFT reviewed Dec 6, 2019

View reviewed changes

lggomez force-pushed the fix_1903 branch 3 times, most recently from cbcfa9c to cd6485b Compare December 16, 2019 23:54

lggomez commented Dec 16, 2019

View reviewed changes

ramya-rao-a reviewed Dec 17, 2019

View reviewed changes

Comment thread src/debugAdapter/goDebug.ts Outdated

ramya-rao-a reviewed Dec 17, 2019

View reviewed changes

ramya-rao-a reviewed Dec 19, 2019

View reviewed changes

Comment thread src/debugAdapter/goDebug.ts Outdated

ramya-rao-a reviewed Dec 19, 2019

View reviewed changes

lggomez force-pushed the fix_1903 branch from f69edcf to be8240c Compare December 20, 2019 02:45

jhendrixMSFT approved these changes Jan 17, 2020

View reviewed changes

ramya-rao-a added the debug label Jan 28, 2020

andrewchoi5 approved these changes Feb 13, 2020

View reviewed changes

Merge branch 'master' of ssh://github.com/microsoft/vscode-go

295cb87

lggomez force-pushed the fix_1903 branch 2 times, most recently from c74b73d to 46fe64c Compare February 17, 2020 03:32

Add stacktrace dump and better error messages on EXC_BAD_ACCESS panics

24e363e

Usability workaround for microsoft#1903

lggomez force-pushed the fix_1903 branch from 46fe64c to 24e363e Compare February 17, 2020 03:37

ramya-rao-a approved these changes Mar 20, 2020

View reviewed changes

ramya-rao-a merged commit 00c318b into microsoft:master Mar 20, 2020

hyangah mentioned this pull request Mar 20, 2020

Sync microsoft/vscode-go@d53b1b3 golang/vscode-go#17

Closed

ramya-rao-a mentioned this pull request Mar 23, 2020

Replace "Failed to continue - bad access" with more informative error message and stack trace. #1903

Closed

lggomez mentioned this pull request Mar 23, 2020

Restore delve detach error message #3123

Merged


		logError(message + ' - ' + errorMessage);

		if (err.toString() === 'bad access') {

Conversation

lggomez commented Nov 14, 2019

Uh oh!

lggomez commented Nov 14, 2019

Uh oh!

lggomez commented Nov 14, 2019

Uh oh!

Uh oh!

ramya-rao-a commented Dec 5, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ramya-rao-a Dec 19, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ramya-rao-a commented Dec 19, 2019

Uh oh!

jhendrixMSFT commented Jan 17, 2020

Uh oh!

lggomezml commented Feb 17, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

ramya-rao-a Dec 19, 2019 •

edited

Loading