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

Rendering causes endless memory allocations on proto messages #660

Open
antoniomacri opened this issue May 18, 2022 · 2 comments
Open

Rendering causes endless memory allocations on proto messages #660

antoniomacri opened this issue May 18, 2022 · 2 comments

Comments

@antoniomacri
Copy link

Consider this:

import (
	. "github.com/smartystreets/goconvey/convey"
	"google.golang.org/protobuf/types/known/wrapperspb"
	"log"
	"testing"
)

func TestConveyBug(t *testing.T) {
	Convey("Given something", t, func() {
		var x = &wrapperspb.BoolValue{Value: false}
		log.Printf("Receive type %v", x)

		So(nil, ShouldResemble, x)
	})
}

When I run this test (I actually used GoLand), it starts allocating memory until I kill it.

The problem seems to be in this function (render.go):

func (s *traverseState) render(buf *bytes.Buffer, ptrs int, v reflect.Value, implicit bool)
@antoniomacri
Copy link
Author

Maybe related to #654?

@antoniomacri
Copy link
Author

antoniomacri commented Jun 8, 2022

I digged a bit deeper. There are two kind of problems:

  1. Comparison of proto Messages performed using ShouldResemble, which is unreliable.
  2. Rendering of failed comparison for proto Messages, which could hit a cycle.

About the first problem I opened another issue (#664).

Regarding the second problem, the call to Printf causes x.String() to be called. This in turn initializes the state and its atomicMessageInfo field on the proto message. Therefore, as stated here, via atomicMessageInfo there may be a problem like a cycle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant