-
Notifications
You must be signed in to change notification settings - Fork 60
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
Internal panic (conflicting position information on upstream object) with latest rules_go #149
Comments
I can confirm this problem is reproduced and it seems to be related to the Currently you can pin the version |
Hey there! I have encountered the same issue today. Is there a possible workaround for it? |
Checked it on @yuxincs @sonalmahajan15 do you currently have any plans on looking into this one? PS / off-topic. It would be nice to have some guidelines on how(if possible) to run the plugin locally, I think it would simplify investigations and make contributions easier. I am thinking if something similar to |
Hi @philipuvarov, we have investigated the issue and the root cause was that the Say we have package dependencies like Naively storing all facts is too expensive in our experiment, and we're investigating smarter ways to tackle this 😃 In the meantime, you can apply this patch that basically disables the "panic" you're seeing: it is not a real panic, it is an artificial safe guard we have placed in NilAway when facts from upstream are incomplete (i.e., cases like this). diff --git a/inference/primitive.go b/inference/primitive.go
index 495dec6..ca360e0 100644
--- a/inference/primitive.go
+++ b/inference/primitive.go
@@ -154,10 +154,11 @@ func newPrimitivizer(pass *analysis.Pass) *primitivizer {
objRepr := site.PkgPath + "." + string(site.ObjectPath)
if existing, ok := upstreamObjPositions[objRepr]; ok && existing != site.Position {
- panic(fmt.Sprintf(
- "conflicting position information on upstream object %q: existing: %v, got: %v",
- objRepr, existing, site.Position,
- ))
+ // panic(fmt.Sprintf(
+ // "conflicting position information on upstream object %q: existing: %v, got: %v",
+ // objRepr, existing, site.Position,
+ // ))
+ return true
}
upstreamObjPositions[objRepr] = site.Position
return true This would disable the panic, but meanwhile due to the incomplete knowledge, false negatives might happen. It's definitely less than ideal (which is why we didn't put this patch into the main branch), and we will try to find a better approach soon.
If you restrict the analysis only to 1st party code, would it still behave that way? (see instructions)
Yeah, this is a bit tricky. I tried this some time ago but to no avail. PRs more than welcome if you've got better ideas here, as always. |
@yuxincs thanks a lot and sorry for the late response!
So funny thing about this, actually it was generated code(protobuf and gRPC) that was causing RAM consumption to go absolutely bonkers, even when running with Nogo. I did remove proto packages with the So after that I have removed generated code packages from the Nogo instrumentation, something like this: go_register_nogo(
excludes = [
+ "@//my/package/proto:__subpackages__",
],
includes = [
+ "@//my/package:__subpackages__",
],
) This has brought down build times back to normal. But also, after excluding generated code from the Nogo, the issue with the upstream panic has gone away. Not sure what or why, but also @yuxincs if you think it might be valuable documenting this Nogo thing(if not for panic, but for performance reasons), I can make a small PR to mention it in the docs(however, it is more Nogo, then NilAway). |
After updating to the latest rules_go and version of nilaway I am now getting the following panic:
✅ nilaway
v0.0.0-20231204220708-2f6a74d7c0e2
works correctly with:rules_go
v0.42golang.org/x/tools
v0.11.0go.mongodb.org/mongo-driver
v0.12.2❌ nilaway
v0.0.0-20231204220708-2f6a74d7c0e2
panics with:rules_go
v0.43golang.org/x/tools
v0.15.0go.mongodb.org/mongo-driver
v0.12.2✅ nilaway
v0.0.0-20231204220708-2f6a74d7c0e2
works correctly with:rules_go
v0.43 with x-tools.patchgolang.org/x/tools
v0.11.0go.mongodb.org/mongo-driver
v0.12.2✅ nilaway
v0.0.0-20231204220708-2f6a74d7c0e2
works correctly with latest master of rules_go:rules_go
b4b04b8dcb221655f64d7eb345ca53b797967d68
with x-tools.patchgolang.org/x/tools
v0.11.0go.mongodb.org/mongo-driver
v0.12.2Finally here's the permalink to the line in the
mongo-driver
package that is apparently causing the panic: https://github.com/mongodb/mongo-go-driver/blob/1f344bd232e6dd3eb70f9d1df3e82cb532191200/mongo/cursor.go#L292The text was updated successfully, but these errors were encountered: