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

runtime: gdb tests fail on NetBSD #22893

Open
bradfitz opened this Issue Nov 27, 2017 · 14 comments

Comments

Projects
None yet
6 participants
@bradfitz
Member

bradfitz commented Nov 27, 2017

The netbsd-amd64-8branch (NetBSD 8.0+) builder is back and NetBSD is kinda working for the first time in ages.

But only kinda.

The runtime tests fail with a timeout about two thirds of the time.

Examples:

https://build.golang.org/log/9ff11d9a995eb3b2555ce8f88bb3280c91639386
https://build.golang.org/log/d9a762c61874b62e34cec30f79ddc21a190922f7
https://build.golang.org/log/7ab9f1d000be47604a25b1ebf17fc55f5799d0ec
https://build.golang.org/log/6678e6c8dfb7533054836eb140f9eff8416e3a30

Many more at https://build.golang.org.

It'd be nice to have NetBSD happy for Go 1.10, considering the Go 1.9 news that NetBSD support was dead (https://golang.org/doc/go1.9#known_issues) which prompted a number of people to help fix things up.

/cc @aclements @ianlancetaylor @bsiegert

@bradfitz bradfitz added this to the Go1.10 milestone Nov 27, 2017

@gopherbot

This comment has been minimized.

gopherbot commented Nov 28, 2017

Change https://golang.org/cl/80136 mentions this issue: runtime: skip GDB tests on NetBSD

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Nov 28, 2017

In each failure a gdb test is timing out. Since the gdb tests are not mission critical, I think we may as well just skip them for now.

gopherbot pushed a commit that referenced this issue Nov 28, 2017

runtime: skip GDB tests on NetBSD
TestGdbAutotmpTypes times out for unknown reasons on NetBSd. Skip the
gdb tests on NetBSD for now.

Updates #22893

Change-Id: Ibb05b7260eabb74d805d374b25a43770939fa5f2
Reviewed-on: https://go-review.googlesource.com/80136
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@krytarowski

This comment has been minimized.

Contributor

krytarowski commented Nov 28, 2017

What are these GDB tests doing? If threading than this is not supposed to work. I work on improvements with ptrace(2) reliability.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Nov 28, 2017

@krytarowski See runtime/runtime-gdb_test.go. I don't know what the actual problem is. I suggest reverting the CL and running go test runtime.

@bradfitz

This comment has been minimized.

Member

bradfitz commented Nov 28, 2017

@krytarowski, if by "threading" you mean tracing a threaded program, then almost certainly yes. Go programs use threads behind the scenes like crazy.

@krytarowski

This comment has been minimized.

Contributor

krytarowski commented Nov 28, 2017

Threads are the reason why golang breaks under GDB/NetBSD.

@aclements

This comment has been minimized.

Member

aclements commented Nov 28, 2017

@krytarowski, thanks. Is this something that's expected to fixed in NetBSD in the near future? If not, I think we should go ahead and close this issue, since there's not much we can do about it.

Also, is there a bug tracking this in NetBSD? It would be nice to reference something canonical from the test skip message.

@bradfitz

This comment has been minimized.

Member

bradfitz commented Nov 28, 2017

I found at least a recent presentation from @krytarowski: http://netbsd.org/~kamil/ptrace-netbsd/presentation.html

@krytarowski

This comment has been minimized.

Contributor

krytarowski commented Nov 28, 2017

http://www.netbsd.org/~kamil/eurobsdcon2017.html a more recent one!

Upstream related Problem Report:

http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=52548 or a prettier link: http://gnats.netbsd.org/52548

I've just finished porting TSan (upstream is ongoing). I'm going to switch to MSan soon and focus on LLDB and ptrace(2) fixes. This will take at least several months (I've estimated 11 months to go..).

@bsiegert

This comment has been minimized.

Contributor

bsiegert commented Nov 28, 2017

http://gnats.netbsd.org/52548 seems to be the most closely related bug.

@bradfitz bradfitz changed the title from runtime: runtime tests fail much of the time on netbsd-amd64 to runtime: gdb tests fail on NetBSD Nov 28, 2017

@bradfitz bradfitz modified the milestones: Go1.10, Unreleased Nov 28, 2017

@gopherbot

This comment has been minimized.

gopherbot commented Nov 30, 2017

Change https://golang.org/cl/81195 mentions this issue: runtime: more specific reason for skipping GDB tests on NetBSD

@krytarowski

This comment has been minimized.

Contributor

krytarowski commented Nov 30, 2017

We have added some quick fixes in gdb from the base that might fix basic tracing golang programs. The fixes landed -current.. 8.0 is getting closer so such upgrades might be too late now in -8. The corrections involve upgrade to GDB-8.0.1

Skipping the tests as of now is reasonable.

gopherbot pushed a commit that referenced this issue Nov 30, 2017

runtime: more specific reason for skipping GDB tests on NetBSD
Updates #22893.

Change-Id: I2cf5efb4fa6b77aaf82de5d8877c99f9aa5d519a
Reviewed-on: https://go-review.googlesource.com/81195
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@bsiegert

This comment has been minimized.

Contributor

bsiegert commented Feb 19, 2018

@krytarowski Would gdb-8.1 from pkgsrc work? We can get a current gdb installed on the builders, and perhaps bail out in the tests if the GDB is below 8.0.1.

@krytarowski

This comment has been minimized.

Contributor

krytarowski commented Feb 19, 2018

Right now the basesystem and pkgsrc GDB are unrelated. The one in pkgsrc is as close to upstream as possible, while the basesystem one contains our patches from the past 20 years.

At the end both should end up as pristine upstream ones, working on it. ETA: after finishing LLDB and fixing ptrace(2).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment