Skip to content

cmd/link: test failure in TestLldbPython from commit 594eae5 onward #25925

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
Closed
siebenmann opened this issue Jun 16, 2018 · 10 comments
Closed

cmd/link: test failure in TestLldbPython from commit 594eae5 onward #25925

siebenmann opened this issue Jun 16, 2018 · 10 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unplanned

Comments

@siebenmann
Copy link

What version of Go are you using (go version)?

go version devel +b459e00454 Sat Jun 16 13:35:45 2018 +0000 linux/amd64

This is the current tip as I file this bug report, but this issue happens from 594eae5 onward; that commit is for issue #11799.

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOOS="linux"

Specifically I'm using Fedora 27, which may matter for this particular failure.

What did you do?

During an all.bash build, I get a test failure reporting unexpected lldb output.

ok      regexp/syntax   0.260s
--- FAIL: TestLldbPython (4.51s)
    runtime-lldb_test.go:178: Unexpected lldb output:
        Created target
        Created breakpoint
        Process launched
        Process state 10
FAIL
FAIL    runtime 23.172s

The Fedora 27 version of lldb appears to be 5.0.2. Based on poking around the Python lldb module, process state 10 appears to be eStateExited on my machine.

I'd be happy to add additional debugging information to the Python that runtime-lldb_test.go uses, or generally test changes.
@odeke-em
Copy link
Member

Thank you @siebenmann for the report and for testing out the latest!

/cc @heschik @ianlancetaylor @aclements

@aarzilli
Copy link
Contributor

LLDB only added support for zdebug sections last month: https://reviews.llvm.org/rL332162

@andybons andybons added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 18, 2018
@andybons andybons added this to the Unplanned milestone Jun 18, 2018
@heschi
Copy link
Contributor

heschi commented Jun 18, 2018 •
edited
Loading

We basically have three options: roll back compression, tell everyone to update lldb, or skip the test. I don't want to roll back compression. Updating lldb is going to be a hassle -- I'm not even sure if that change has hit a release yet. So I'm inclined to skip the test and we can re-enable it once lldb has released the change @aarzilli linked to. Or maybe make it a long test so that people are less likely to run it?

@aclements
Copy link
Member

I agree. Can we detect when we should skip the test so it's not just permanently skipped?

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/119535 mentions this issue: runtime: fix lldb test after DWARF compression

@heschi
Copy link
Contributor

heschi commented Jun 18, 2018

Okay, I skipped the test if the breakpoint doesn't match any locations. Not perfect but the best I could come up with.

@siebenmann, please try the above CL? I think it'll fix it but the test times out on my machine.

@siebenmann
Copy link
Author

@heschik, your CL fixes the issue on my Fedora machine; all tests now pass and Go tip (+ the change) builds without problems.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/124386 mentions this issue: Revert "runtime: fix lldb test after DWARF compression"

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/124385 mentions this issue: runtime: disable compressed DWARF for lldb test

gopherbot pushed a commit that referenced this issue Jul 17, 2018
@aclements
runtime: disable compressed DWARF for lldb test
ff5b54d 
lldb doesn't support compressed DWARF, so right now we're just always
skipping the lldb test. This CL makes the test run again by disabling
compressed DWARF just for this test.

Updates #25925.

Change-Id: Ib9ddc442305fe6d37060d48f36bc4458b6fd8c86
Reviewed-on: https://go-review.googlesource.com/124385
Run-TryBot: Austin Clements <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Brad Fitzpatrick <[email protected]>
gopherbot pushed a commit that referenced this issue Jul 17, 2018
@aclements
Revert "runtime: fix lldb test after DWARF compression"
57b5a71 
This reverts commit c993002.

The original CL skipped the lldb test if it couldn't read compressed
DWARF, but lldb can never read compressed DWARF, so this effectively
disabled this test unconditionally.

The previous commit disabled DWARF compression for this test, so the
test now works on its own merits again. This CL reverts the change to
skip the test so we don't simply mask lldb failures.

Updates #25925.

Change-Id: I3e1c787b658257b542c3c70807065dde9cfe05ee
Reviewed-on: https://go-review.googlesource.com/124386
Run-TryBot: Austin Clements <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Brad Fitzpatrick <[email protected]>
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/124712 mentions this issue: cmd/compile: avoid compressed dwarf when testing for gdb on OSX

gopherbot pushed a commit that referenced this issue Jul 19, 2018
@dr2chase
cmd/compile: avoid compressed dwarf when testing for gdb on OSX
2fe2aa0 
Until we figure out how to deal with gdb on Darwin (doesn't
read compressed DWARF from binaries), avoid compressing
DWARF in that case so that the test will still yield meaningful
results.

This is also reported to be a problem for Windows.

Problem also exists for lldb, but this test doesn't check
lldb.

Updates #25925

Change-Id: I85c0e5db75f3329957290500626a3ac7f078f608
Reviewed-on: https://go-review.googlesource.com/124712
Run-TryBot: David Chase <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Heschi Kreinick <[email protected]>
@golang golang locked and limited conversation to collaborators Jul 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
7 participants
@aarzilli @andybons @siebenmann @aclements @odeke-em @gopherbot @heschi