windows: Adapter.Scan and DeviceCharacteristic.Read memory leaks

[5k3105]

Steady memory leak when using either of these calls on windows.

Ive tested v 13 14 15 and dev. In v14 the memory leak in Scan disappeared, but has come back in 15 and dev.

My program will Scan or Read in a loop with 1 second waits.

Im not sure what other info would be helpful.

[acouvreur]

Hi @5k3105

Can you provide us with a reproducible script ?

And can you share your observation data ? How do you see the memory leak ?

Would you be able to submit a patch / dig into the windows code ?

[5k3105]

func read() {
	adapter := bluetooth.DefaultAdapter
	mac := "address.."
	macaddr := bluetooth.MACAddress{}
	macaddr.Set(mac)
	address := bluetooth.Address{macaddr}
	adapter.Enable()
	dev, err := adapter.Connect(
		address,
		bluetooth.ConnectionParams{},
	)
	if err != nil {
		panic(err)
	}

	svc, _ := bluetooth.ParseUUID("uid..")
	chr, _ := bluetooth.ParseUUID("uid..")
	services, err := dev.DiscoverServices([]bluetooth.UUID{svc})
	if err != nil {
		panic(err)
	}

	chars, err := services[0].DiscoverCharacteristics([]bluetooth.UUID{chr})
	if err != nil {
		panic(err)
	}
	c := chars[0]
	data := make([]byte, 60)

	for {
		time.Sleep(1 * time.Second)
		num, err := c.Read(data)
		if err != nil {
			fmt.Println(err.Error())
			continue
		}
		fmt.Println(":", num, data)
	}
}

func scan() {
	adapter := bluetooth.DefaultAdapter
	adapter.Enable()
	err := adapter.Scan(func(adapter *bluetooth.Adapter, device bluetooth.ScanResult) {
		print(".")
		time.Sleep(1 * time.Second)

	})
	if err != nil {
		fmt.Println("Scan error:", err.Error())
	}
}

I can see the memory leak by watching the windows task manager. I've let it run for days and memory starts at 3mb and rises past 500mb on the 2nd day.

I've looked at the windows code

bluetooth/gattc_windows.go

Line 385 in fc635e3

func (c DeviceCharacteristic) Read(data []byte) (int, error) {

then

bluetooth/adapter_windows.go

Line 45 in fc635e3

func awaitAsyncOperation(asyncOperation *foundation.IAsyncOperation, genericParamSignature string) error {

so I havent gone too far ..

[acouvreur]

I've actually found a lot of memory leak.

I'm trying to write a linter that can check those memory leaks.

[acouvreur]

I'm pushing a PR with the memory leak fixes.

Can you try using that branch ?

go get tinygo-org/bluetooth@windows-memory-leaks

[acouvreur]

Please take a look at #453 too @5k3105

[5k3105]

Thanks for working on this. Unfortunately that didnt fix the problem.

I cut out the scan code yesterday like this, some call inside this is leaking:

package main

import (
	"fmt"
	"time"
	"tinygo.org/x/bluetooth"

	"unsafe"

	"github.com/go-ole/go-ole"
	"github.com/saltosystems/winrt-go"
	"github.com/saltosystems/winrt-go/windows/devices/bluetooth/advertisement"
	"github.com/saltosystems/winrt-go/windows/foundation"
)

var result bluetooth.ScanResult

type Adapter_ struct {
	*bluetooth.Adapter
}

func scan() {
	adapter := bluetooth.DefaultAdapter
	adapter.Enable()
	adapter_ := Adapter_{adapter}
	err := adapter_.Scan(func(adapter *Adapter_, device bluetooth.ScanResult) {
		rssi := fmt.Sprintf("%vdBm", device.RSSI)
		println(rssi)
		time.Sleep(1 * time.Second)
	})
	if err != nil {
		fmt.Println("Scan error:", err.Error())
	}
}

func getScanResultFromArgs(args *advertisement.BluetoothLEAdvertisementReceivedEventArgs) bluetooth.ScanResult {
	addr, _ := args.GetBluetoothAddress()
	adr := bluetooth.Address{}
	for i := range adr.MAC {
		adr.MAC[i] = byte(addr)
		addr >>= 8
	}
	sigStrength, _ := args.GetRawSignalStrengthInDBm()
	result := bluetooth.ScanResult{
		RSSI:    sigStrength,
		Address: adr,
	}

	return result
}

func (a *Adapter_) Scan(callback func(*Adapter_, bluetooth.ScanResult)) (err error) {
	watcher, err := advertisement.NewBluetoothLEAdvertisementWatcher()
	if err != nil {
		return
	}

	defer watcher.Release()

	
	// Set scanning mode to active so we receive scan responses
	// from devices in advertising mode
	err = watcher.SetScanningMode(advertisement.BluetoothLEScanningModeActive)
	if err != nil {
		return
	}

	// Listen for incoming BLE advertisement packets.
	// We need a TypedEventHandler<TSender, TResult> to listen to events, but since this is a parameterized delegate
	// its GUID depends on the classes used as sender and result, so we need to compute it:
	// TypedEventHandler<BluetoothLEAdvertisementWatcher, BluetoothLEAdvertisementReceivedEventArgs>
	eventReceivedGuid := winrt.ParameterizedInstanceGUID(
		foundation.GUIDTypedEventHandler,
		advertisement.SignatureBluetoothLEAdvertisementWatcher,
		advertisement.SignatureBluetoothLEAdvertisementReceivedEventArgs,
	)
	handler := foundation.NewTypedEventHandler(ole.NewGUID(eventReceivedGuid), func(instance *foundation.TypedEventHandler, sender, arg unsafe.Pointer) {
		args := (*advertisement.BluetoothLEAdvertisementReceivedEventArgs)(arg)
		result = getScanResultFromArgs(args)
		callback(a, result)
	})
	defer handler.Release()

	token, err := watcher.AddReceived(handler)
	if err != nil {
		return
	}
	defer watcher.RemoveReceived(token)
	

	stoppingChan := make(chan error)
	
	eventStoppedGuid := winrt.ParameterizedInstanceGUID(
		foundation.GUIDTypedEventHandler,
		advertisement.SignatureBluetoothLEAdvertisementWatcher,
		advertisement.SignatureBluetoothLEAdvertisementWatcherStoppedEventArgs,
	)
	
	stoppedHandler := foundation.NewTypedEventHandler(ole.NewGUID(eventStoppedGuid), func(_ *foundation.TypedEventHandler, _, arg unsafe.Pointer) {

		args := (*advertisement.BluetoothLEAdvertisementWatcherStoppedEventArgs)(arg)
		_, err := args.GetError()
		if err != nil {
			stoppingChan <- fmt.Errorf("failed to get stopping error value: %w", err)
		}
	
		close(stoppingChan)
	})
	defer stoppedHandler.Release()

	token, err = watcher.AddStopped(stoppedHandler)
	if err != nil {
		return
	}
	defer watcher.RemoveStopped(token)

	err = watcher.Start()
	if err != nil {
		return err
	}

	return <-stoppingChan
}

[5k3105]

I noticed go-ole has a v2 branch. Unfortunately I wasnt able to require it in my mod file because go mod doesnt like branches called v2, only tags (it seems)..

[acouvreur]

Hey @5k3105 what kind of growth do you measure ?

I built a small leak detector and this what I observe:

=== RUN   TestScanMemoryLeak
    gap_windows_leak_test.go:122: baseline private bytes: 16 MB
    gap_windows_leak_test.go:134: batch 1/8: 16 MB total, growth +216 KB
    gap_windows_leak_test.go:134: batch 2/8: 16 MB total, growth +164 KB
    gap_windows_leak_test.go:134: batch 3/8: 17 MB total, growth +372 KB
    gap_windows_leak_test.go:134: batch 4/8: 17 MB total, growth +0 KB
    gap_windows_leak_test.go:134: batch 5/8: 17 MB total, growth +256 KB
    gap_windows_leak_test.go:134: batch 6/8: 17 MB total, growth +0 KB
    gap_windows_leak_test.go:134: batch 7/8: 17 MB total, growth +36 KB
    gap_windows_leak_test.go:134: batch 8/8: 17 MB total, growth +60 KB
    gap_windows_leak_test.go:150: average growth per batch (last 3 batches): 32 KB

Here's the code if you need it:

//go:build windows && integration

package bluetooth

// Memory leak integration tests for Windows COM/WinRT objects.
//
// These tests measure process private bytes (PagefileUsage) — the memory
// category that includes natively-allocated COM objects not tracked by Go's GC.
// runtime.ReadMemStats will NOT detect these leaks.
//
// Run with:
//
//	go test -tags integration -v -run TestScanMemoryLeak .

import (
	"os"
	"runtime"
	runtimedebug "runtime/debug"
	"syscall"
	"testing"
	"time"
	"unsafe"
)

var (
	modPsapi                 = syscall.NewLazyDLL("psapi.dll")
	procGetProcessMemoryInfo = modPsapi.NewProc("GetProcessMemoryInfo")
)

// processMemoryCounters mirrors PROCESS_MEMORY_COUNTERS from psapi.h.
// PagefileUsage corresponds to "Private Bytes" in Task Manager / Process Explorer,
// which is the metric that grows when WinRT/COM objects are not Released.
type processMemoryCounters struct {
	CB                         uint32
	PageFaultCount             uint32
	PeakWorkingSetSize         uintptr
	WorkingSetSize             uintptr
	QuotaPeakPagedPoolUsage    uintptr
	QuotaPagedPoolUsage        uintptr
	QuotaPeakNonPagedPoolUsage uintptr
	QuotaNonPagedPoolUsage     uintptr
	PagefileUsage              uintptr // "Private Bytes"
	PeakPagefileUsage          uintptr
}

// privateBytes returns the current process private bytes.
// COM/WinRT objects live here (not on the Go heap) until Release() is called.
func privateBytes(t *testing.T) uintptr {
	t.Helper()
	handle, err := syscall.GetCurrentProcess()
	if err != nil {
		t.Fatalf("GetCurrentProcess: %v", err)
	}
	var mc processMemoryCounters
	mc.CB = uint32(unsafe.Sizeof(mc))
	r, _, callErr := procGetProcessMemoryInfo.Call(
		uintptr(handle),
		uintptr(unsafe.Pointer(&mc)),
		uintptr(mc.CB),
	)
	if r == 0 {
		t.Fatalf("GetProcessMemoryInfo: %v", callErr)
	}
	return mc.PagefileUsage
}

// TestScanMemoryLeak verifies that repeated Scan+StopScan cycles do not leak
// native COM/WinRT memory (issue #451).
//
// No specific BLE device is needed, just a BLE adapter. Nearby devices
// advertising are fine; their first discovery may cause WinRT to grow its
// internal BLE device registry (expected). This test distinguishes that
// one-time cache-fill from a sustained linear leak.
//
// Strategy: run scans in batches and track growth per batch. WinRT caching
// shows large growth in early batches that tapers off. A real leak in our code
// shows consistent growth in every batch, including the last ones.
func TestScanMemoryLeak(t *testing.T) {
	if err := DefaultAdapter.Enable(); err != nil {
		t.Skipf("BLE adapter not available: %v", err)
	}

	const (
		scanDuration = 500 * time.Millisecond
		warmupRounds = 5
		batchSize    = 5
		batches      = 8 // 40 scan rounds total after warmup

		// Growth allowed per batch in the final 3 batches.
		// By then WinRT's device cache should be saturated, so only a real
		// per-scan-session leak in our code would exceed this.
		maxSustainedGrowthPerBatch = 256 * 1024 // 256 KB
	)

	runOneScan := func() {
		go func() {
			time.Sleep(scanDuration)
			_ = DefaultAdapter.StopScan()
		}()
		_ = DefaultAdapter.Scan(func(_ *Adapter, _ ScanResult) {})
	}

	// Warm up: let WinRT initialise its thread pools and prime its caches.
	for i := 0; i < warmupRounds; i++ {
		runOneScan()
	}

	// measureNative forces the Go GC to release all idle heap spans back to the
	// OS before sampling private bytes. This ensures the reported figure
	// reflects native (COM/WinRT) allocations rather than retained Go heap.
	measureNative := func() uintptr {
		runtime.GC()
		runtimedebug.FreeOSMemory() // return idle Go spans to OS
		return privateBytes(t)
	}

	// Measure memory after each batch of scans.
	measures := make([]uintptr, batches+1)
	measures[0] = measureNative()
	t.Logf("baseline private bytes: %d MB", measures[0]>>20)

	for b := 0; b < batches; b++ {
		for i := 0; i < batchSize; i++ {
			runOneScan()
		}
		measures[b+1] = measureNative()

		var delta int64
		if measures[b+1] > measures[b] {
			delta = int64(measures[b+1] - measures[b])
		}
		t.Logf("batch %d/%d: %d MB total, growth %+d KB",
			b+1, batches, measures[b+1]>>20, delta>>10)
	}

	// Check whether growth is *sustained* in the final 3 batches.
	// WinRT cache-fill growth is front-loaded and tapers off; a per-session
	// COM leak grows at a constant rate in every batch including the last.
	const checkBatches = 3
	var lastGrowth uintptr
	for i := batches - checkBatches + 1; i <= batches; i++ {
		if measures[i] > measures[i-1] {
			lastGrowth += measures[i] - measures[i-1]
		}
	}
	avgLast := lastGrowth / checkBatches

	t.Logf("average growth per batch (last %d batches): %d KB", checkBatches, avgLast>>10)

	if avgLast > maxSustainedGrowthPerBatch {
		t.Errorf("sustained memory leak: avg %d KB/batch in last %d batches (threshold: %d KB) — "+
			"this indicates a per-scan-session COM object is not being Released",
			avgLast>>10, checkBatches, maxSustainedGrowthPerBatch>>10)
	}
}

[acouvreur]

For example, commenting out all .Release() in gap_windows.go gives us this result:

    gap_windows_leak_test.go:122: baseline private bytes: 18 MB
    gap_windows_leak_test.go:134: batch 1/8: 20 MB total, growth +2872 KB
    gap_windows_leak_test.go:134: batch 2/8: 23 MB total, growth +2720 KB
    gap_windows_leak_test.go:134: batch 3/8: 26 MB total, growth +2768 KB
    gap_windows_leak_test.go:134: batch 4/8: 28 MB total, growth +2460 KB
    gap_windows_leak_test.go:134: batch 5/8: 30 MB total, growth +2264 KB
    gap_windows_leak_test.go:134: batch 6/8: 33 MB total, growth +2396 KB
    gap_windows_leak_test.go:134: batch 7/8: 35 MB total, growth +2464 KB
    gap_windows_leak_test.go:134: batch 8/8: 37 MB total, growth +2324 KB

---

Checking out the version in dev gives us this result:

    gap_windows_leak_test.go:122: baseline private bytes: 18 MB
    gap_windows_leak_test.go:134: batch 1/8: 21 MB total, growth +2376 KB
    gap_windows_leak_test.go:134: batch 2/8: 23 MB total, growth +2456 KB
    gap_windows_leak_test.go:134: batch 3/8: 25 MB total, growth +2116 KB
    gap_windows_leak_test.go:134: batch 4/8: 27 MB total, growth +1756 KB
    gap_windows_leak_test.go:134: batch 5/8: 29 MB total, growth +1976 KB
    gap_windows_leak_test.go:134: batch 6/8: 31 MB total, growth +2100 KB
    gap_windows_leak_test.go:134: batch 7/8: 32 MB total, growth +1800 KB
    gap_windows_leak_test.go:134: batch 8/8: 35 MB total, growth +2576 KB

And the version in #453 gives us this result:

    gap_windows_leak_test.go:122: baseline private bytes: 16 MB
    gap_windows_leak_test.go:134: batch 1/8: 16 MB total, growth +308 KB
    gap_windows_leak_test.go:134: batch 2/8: 16 MB total, growth +0 KB
    gap_windows_leak_test.go:134: batch 3/8: 17 MB total, growth +392 KB
    gap_windows_leak_test.go:134: batch 4/8: 17 MB total, growth +36 KB
    gap_windows_leak_test.go:134: batch 5/8: 16 MB total, growth +0 KB
    gap_windows_leak_test.go:134: batch 6/8: 17 MB total, growth +288 KB
    gap_windows_leak_test.go:134: batch 7/8: 17 MB total, growth +16 KB
    gap_windows_leak_test.go:134: batch 8/8: 17 MB total, growth +0 KB

I'd say that this is already very promising. I'm not sure if we should expect always +0 KB ? But that's definitely far better than before.

[5k3105]

Your tests look better, yes. In one configuration in v14 running Scan I was able to get 0kb increase. I was only able to reproduce that condition twice... and I didnt save what the mod file looked like unfortunately. I tried building with v14 again today and it didnt work..

The Scan and Read Im running is expected to run concurrently for months, so there can't be any memory leaks.
I will try to find a way to use the v2 version of go-ole tomorrow to see if that helps.

Thanks for all your work.

[acouvreur]

What do you mean by v14 ?