memory leak in cuecontext.CompileString?

[abngoal]

package main

import (
	"log"
	"time"

	"cuelang.org/go/cue/cuecontext"
)

func main() {
	for {
		parse()
		time.Sleep(10 * time.Millisecond)
	}
}

func parse() {
	var err error
	ctx := cuecontext.New()

	value := ctx.CompileString(schema)
	if err = value.Err(); err != nil {
		log.Fatalln(err)
	}
}

const schema = `
#testa: int
#testb: int
`

i use the goapi in my server In the same way as above. However, I found that frequent calls to 'CompileString' led to uncontrolled memory.
Maybe I'm using it wrong. Who can tell me how to use the api correctly

[eonpatapon]

Maybe reuse the same cuecontext ? You don't need to create a new one everytime.

[verdverm]

I don't believe this is a memory leak as much as the shared index building up over time and not releasing memory. The evaluator currently has some global stuff which is why you cannot perform certain operations without locking and the memory footprint will increase indefinitely.

At this point, you will have to do hacky things for long running CUE processes. (i.e. gracefully restart the server every so often and run enough copies to keep the API available)

If you are using the same schema on every call, it will be beneficial to parse it once and reuse it in subsequent calls.

note, this is expected to change over time. there are other issues tracking these features

[abngoal]

@verdverm thanks for your answer. I'm going to try to solve this problem by calling cue directly, although the performance will be worse

[abngoal]

Maybe reuse the same cuecontext ? You don't need to create a new one everytime.

I have tried this method, and the problem is still there but not as severe as before

[kentalee]

cuecontext.New() call internal/core/runtime/Runtime.New(), which create new runtime object with global sharedIndex @ internal/core/runtime/imports.go :

// sharedIndex is used for indexing builtins and any other labels common to
// all instances.
var sharedIndex = newIndex()

instances built by runtime are used by the global variable sharedIndex, and will not be freed after cueContext delete by gc

Perhaps similar to #1418 #1414

[kentalee]

maybe this fix could help (on your own risk): https://github.com/lipence/cue/commit/6ed69100ebd62509577826657536172ab46cf257

replace cuelang.org/go => github.com/lipence/cue v0.4.1-beta.6a

[abngoal]

@kentalee

replace cuelang.org/go => github.com/lipence/cue v0.4.1-beta.6a

it works!

[verdverm]

I kind of think #1418 is better in that it raises the idea of letting users configure the index scope.

• I may want to use a single, shared index, such that it doesn't matter which context values are created with, they can still be unified and compared
• I may want each index to be isolated and independent, for example a long running API service
• I may want something in the middle, where I create a global context containing schemas, and then create a new context as a clone of this global, so that I can isolate independent request while still benefiting from only parsing the schemas once

I don't think CUE can necessarily infer when I may be done with a value, so we probably need a way for users to control this due to the memory pressure the current behavior creates.

[mpvl]

@kentalee: yes, that is indeed the problem. There was some reason why this wasn't done yet exactly as you said.

I think part of the issue was that builtins could not yet be treated the same way, even though this is not possible yet and then a proper fix for the packages, at least, dropped off the radar.

@eonpatapon: in this case, to avoid growing memory, one actually _should _create a new Context on each iteration. The problem is indeed as @kentalee identified.