[acouvreur]

A Go thread has no autorelease pool, so an object autoreleased by a call from Go stays allocated until its thread exits, which Go threads rarely do. Every characteristic write kept its NSData: 280 bytes for a 244-byte write.

Every function that calls into Objective-C now starts with defer popPool(pushPool()): an autorelease pool, pushed on a locked thread and drained when the function returns, after it has copied any C string or bytes that point into the released objects.

btleplug fixed the same leak in its CoreBluetooth backend: deviceplug/btleplug#494 reported memory growing without bound while scanning, and deviceplug/btleplug@0250198 wraps each message on its CoreBluetooth thread in objc_autoreleasePoolPush/Pop. cbgo has no thread of its own for calls from Go, so the pool goes around each call instead.

Draining exposed what the leak hid:

• Nine arrays and buffers were autoreleased twice (scan, advertising, updateValue, and the service and characteristic setters), which over-releases them once a pool drains.
• str_to_nsstring and str_to_nsuuid returned objects that nothing released. They now return them autoreleased, like the other helpers.
• The peripherals the retrieve calls return were kept alive only by the leaked array. They are now retained, like the ones the delegate hands to Go.

The tests measure the C heap over 10000 calls, with nil receivers where a call would need a Bluetooth controller, and check that every function calling into Objective-C starts with the pool. CI now runs them.

Tested on macOS 15.8.1 against an ESP32-S3 peripheral through tinygo-org/bluetooth v0.16.0: connect by identifier, a read of every service, and seven complete uploads of 404 to 461 KB. go build, go vet and go test pass, and the package builds for ios/arm64.

🤖 Generated with Claude Code