Panic in buildTreeFromParentPointerTrees

[kolesnikovae]

I've discovered a panic stack trace that indicates a problem in buildTreeFromParentPointerTrees:

However, the problem is apparently somewhere in the SplitStacktraceIDRanges implementation (PartitionWriter), presumably in SampleAppender.Samples:

resolver_tree.go

	// If the number of samples is large (> 128K) and the StacktraceResolver
	// implements the range iterator, we will be building the tree based on
	// the parent pointer tree of the partition (a copy of). The only exception
	// is when the number of nodes is not limited, or is close to the number of
	// nodes in the original tree: the optimization is still beneficial in terms
	// of CPU, but is very expensive in terms of memory.
	iterator, ok := symbols.Stacktraces.(StacktraceIDRangeIterator)
	if ok && shouldCopyTree(appender, maxNodes) {
		ranges := iterator.SplitStacktraceIDRanges(appender) // <--------------- The problem is apparently here
		return buildTreeFromParentPointerTrees(ctx, ranges, symbols, maxNodes)
	}
	// Otherwise, use the basic approach: resolve each stack trace
	// and insert them into the new tree one by one. The method
	// performs best on small sample sets.
	samples := appender.Samples()
	t := treeSymbolsFromPool()
	defer t.reset()
	t.init(symbols, samples)
	if err := symbols.Stacktraces.ResolveStacktraceLocations(ctx, t, samples.StacktraceIDs); err != nil {
		return nil, err
	}
	return t.tree.Tree(maxNodes, t.symbols.Strings), nil

The query that caused the panic targets large in-memory data set, and I can't reproduce it easily.

One way to solve the problem is to disable the optimization: it was added relatively recently (a couple of month ago) and is only helpful when the stack trace tree includes millions of nodes.

However, I'm going to disable stack trace chunking (into ranges) altogether – this piece is useless but complicates a lot of things – this will not fix the problem for already written data, but will prevent this for happening in the future