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.

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

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

Closed
siebenmann opened this issue Jun 16, 2018 · 10 comments

Comments

Projects
None yet
7 participants
@siebenmann
Copy link

commented Jun 16, 2018

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

This comment has been minimized.

Copy link
Member

commented Jun 16, 2018

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

/cc @heschik @ianlancetaylor @aclements

@aarzilli

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2018

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

@andybons andybons added this to the Unplanned milestone Jun 18, 2018

@heschik

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2018

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

This comment has been minimized.

Copy link
Member

commented Jun 18, 2018

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

@gopherbot

This comment has been minimized.

Copy link

commented Jun 18, 2018

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

@heschik

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Author

commented Jun 18, 2018

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

@gopherbot gopherbot closed this in c993002 Jun 18, 2018

@gopherbot

This comment has been minimized.

Copy link

commented Jul 17, 2018

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

@gopherbot

This comment has been minimized.

Copy link

commented Jul 17, 2018

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

runtime: disable compressed DWARF for lldb test
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 <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

gopherbot pushed a commit that referenced this issue Jul 17, 2018

Revert "runtime: fix lldb test after DWARF compression"
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 <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@gopherbot

This comment has been minimized.

Copy link

commented Jul 18, 2018

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

cmd/compile: avoid compressed dwarf when testing for gdb on OSX
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 <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.