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: sweep increased allocation count #31006
Comments
This error is commonly caused by invalid use of unsafe or cgo. Do you use unsafe or cgo? |
To answer my own question: yes. A fair bit. e.g. https://gitlab.com/YottaDB/Lang/YDBGo/blob/master/buffer_t.go#L51 Have you audited it for correctness? |
Please try again with GODEBUG=cgocheck=2 per https://golang.org/cmd/cgo/#hdr-Passing_pointers |
Yes, we use cgo and unsafe a fair amount. We've audit'd it for correctness as part of our review process, and have a number of tests which pass without issue. Some of those tests are rather long living, and do a great deal of intensive operations against our API. With your suggestion to use the more strict cgocheck, we get the same result.
|
What was the outcome of this issue? I see it is "waiting more info", but it has also been added to some milestones. Is there a legitimate bug in the runtime that needs fixing? |
Paul, probably not. Not without a repro. Or several independent reports. This is usually caused by incorrect unsafe code. There's new validation functionality in Go 1.14 to help users find such code though. |
Great. Are those additional checks in 1.14 currently in master? Any docs yet? |
I am no longer at YottaDB, but, I believe this ended up being an issue with
how Go/YottaDB did signal handling.
I will let the folks at YottaDB know this got a response and get back to
you.
Thanks!
Charles
…On Wed, Dec 18, 2019, 21:02 Paul Knopf ***@***.***> wrote:
Great. Are those additional checks in 1.14 currently in master? Any docs
yet?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#31006?email_source=notifications&email_token=AAVFDFISOUTYN5GS5E67LU3QZL573A5CNFSM4HAQ27L2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHINKSQ#issuecomment-567334218>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAVFDFJHK5BGLED5WIHKMH3QZL573ANCNFSM4HAQ27LQ>
.
|
@pauldotknopf, https://tip.golang.org/doc/go1.14#compiler ...
|
@chathaway-codes, I'll close this for now until there's something actionable for us to look into. If YottaDB folk have a repro we'd love to look. |
Quick update. I was experiencing this error with 1.9. The error is very rare (only once so far, over the course of many many hours), but I could get the error to happen immediately with these env vars.
When I updated to 1.13, when using the above env vars, I couldn't get the error to reproduce. |
It's not clear whether we actually solved a problem, or just worked around one, but after running across #23576 we made sure that we were forwarding signals only when our code was at safe points. Owing to YottaDB's database engine that runs in the address space of a process and optimistic concurrency control (https://docs.yottadb.com/MultiLangProgGuide/MultiLangProgGuide.html#transaction-processing), runtime stacks with ACID transaction logic have Go calling C calling Go (https://docs.yottadb.com/MultiLangProgGuide/goprogram.html#go-tpe and https://docs.yottadb.com/MultiLangProgGuide/goprogram.html#go-tpst). In any case, the YottaDB Go wrapper is stable and considered production grade. So, it is appropriate to close this Issue. Thank you. |
i have got this problem too |
@TUTUBIG This issue is closed. If you still have this problem with Go 1.14 or 1.15, please open a new issue with instructions for how to reproduce the problem. Thanks. |
go env 1.15 , but I hvve this problem, and can't find way to reproduce this problem, runtime: nelems=28 nalloc=2 previous allocCount=1 nfreed=65535 runtime stack: |
@childeYin This issue is closed. If you still have this problem with Go 1.14 or 1.15, please open a new issue with instructions for how to reproduce the problem. Thanks. |
Even if you can't reproduce the problem, it's still a different problem. It just happens to have the same symptoms. |
What version of Go are you using (
go version
)?We've encountered this issue with go versions:
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?We've seen it on a number of boxes running x86_64 processors and various operating systems. To help debug this, we've reproduced it in a Docker container. Information below is from the Docker container.
go env
OutputWhat did you do?
We (YottaDB) have written a Go wrapper for our NoSQL database. The codebase for the database is used in production in many places, the Go wrapper is currently declared "field test grade". We have a test which exercises various methods in our wrapper, and it seems to consistently produce an error message if GOGC is set low enough.
What did you expect to see?
A successful run
What did you see instead?
A crash. The crash was rare, until we found some other bug reports which suggested setting GOGC low to reproduce it.
We've also seen errors like this:
We've stashed the test environment in a Docker container which can be pulled with:
To rerun the test in that Docker container:
The source code for the test program which produces this crash is available at https://gitlab.com/YottaDB/DB/YDBTest/blob/master/go/inref/random_walk_test.go. The YDBGo wrapper (https://gitlab.com/YottaDB/Lang/YDBGo) has CI setup which includes running
go test
withrace
, and we manually verified that the test script has no race conditions.With
GODEBUG=gccheckmark=1
set, this doesn't seem to reproduce as often. I don't see anything extra in the output of a crash though.Thanks in advance for the help!
The text was updated successfully, but these errors were encountered: