[drasmart]

Carried over from device-detection-go#102 by James Rosewell, a draft with no review yet, while device-detection-go is being merged into this repository. The branch is brought in as is, with its original commits, so the changes are under device-detection/.

---

Closes #3

Problem

fiftyoneDegreesExceptionGetMessage allocates its message with the library's Malloc and the caller must free it. Twelve places in dd copied the message into a Go error with C.GoString and never freed it, so every failed call leaked one message. The status message in InitManagerFromFile was freed with MemoryStandardFree rather than the Free that partners Malloc. All thirteen passed the message to fmt.Errorf as its format string, so a % in a data file path was garbled. ReloadFromFile also copied its file name with C.CString and never freed the copy. #3 has the details and a link to each place.

Change

• dd/exception.go adds messageError, which copies a message the C library allocated into an error with errors.New and then frees it. Go cannot call a C function pointer, so the free goes through freeMessage, a static C function in the cgo preamble that calls fiftyoneDegreesFree.
• dd/config_hash.go, dd/resource_hash.go and dd/results_hash.go call messageError at the twelve exception sites and the status site. config_hash.go no longer imports fmt.
• ReloadFromFile frees its copy of the file name.
• dd/memory.go adds allocatedDuring, which runs a call with the library's memory tracking switched on and returns the bytes still allocated afterwards.
• dd/exception_test.go adds TestMessageError, which checks that the message for a missing file called missing-%d.hash holds the path unchanged, and TestMessageFreed, which checks that a failed InitManagerFromFile leaves nothing allocated through the exception path (LowMemory) and through the status path (InMemory).

Both tests use only a missing file. Like every test in dd, they need the Lite data file that TestMain looks for.

Verification

Windows 11, Go 1.25.1, MSYS2 UCRT64 gcc 16.2.0, CGO_ENABLED=1, with 51Degrees-LiteV4.1.hash at the repository root and in assets/, where TestMain and the onpremise tests look for it. "Before" is 100f55d and "after" is 4b5857d.

Check	Before	After
go build -p 2 ./...	passes	passes
go vet -p 2 ./dd ./onpremise	clean	clean
go vet -p 2 ./dd ./onpremise with go.mod temporarily set to go 1.24	13 findings, "non-constant format string in call to fmt.Errorf"	clean
go test -p 2 -count=1 ./dd	passes	passes
go test -p 2 -count=1 ./onpremise	passes	passes
go test -p 2 -count=1 -v -run 'TestMessageError|TestMessageFreed' ./dd	TestMessageError fails with missing-%!d(MISSING).hash, TestMessageFreed/exception leaves 218 bytes, TestMessageFreed/status leaves 193 bytes	passes
Bytes left after 1,000 failed InitManagerFromFile calls, missing file, LowMemory	218,000	0
Bytes left after 1,000 MatchEvidence calls with freed evidence	195,000	0
Growth in private bytes over 1,000 ReloadFromFile calls with a 65,617 character path	66,797,568	790,528

For the "before" run of the two tests, the four production files were reset to 100f55d and the tests were kept. In the status case the old code did free the message, but with MemoryStandardFree, which the library's tracking does not see, so the tracker still counted its 193 bytes.

The last three rows come from local checks that are not committed. The first two wrap fiftyoneDegreesSetUpMemoryTracking and fiftyoneDegreesUnsetMemoryTracking around the calls. The third reads the process's private bytes through GetProcessMemoryInfo, so it only runs on Windows.

go vet ./... fails at 100f55d on four unkeyed struct literals in examples/uach/uach_test.go, which this change does not touch, so vet was run on the two library packages.

CI

The shared build and test workflow only picks up pull requests that are not drafts, so the build and test matrix has not run on this pull request. The UTM link lint is the only check that runs on a draft.

What remains

• There is no committed test for the file name. C.CString allocates with C's malloc, which the library's tracking does not see, and Go has no portable way to read the C heap.
• ReloadFromFile and ReloadFromOriginalFile discard the status code that the C reload returns, so a failed reload reports success. That is not changed here. It is ReloadFromFile and ReloadFromOriginalFile report success when a reload fails #4, fixed in FIX: Return the status of a failed reload as an error #6, which is stacked on this one.