-3

I'm trying to use Golang's win64api library(https://github.com/kumako/go-win64api) to control windows firewall.

It works well, but it doesn't release memory. For example, running functions in a loop will cause continuous incremental memory usage.

Looking at the library, it seems that this topic is taken care of(functions like firewallAPIRelease, firewallRulesEnumRealease).

Does anyone have an idea why this is happening?

Here's a code that causes the problem:

package main

import (
    "fmt"
    winapi "github.com/kumako/go-win64api"
    "time"
)

func main(){
    var first string
    for 1>0 {
        fmt.Scanln(&first)
        if first == "run"{
            firewallTest()
        }
    }
}

func firewallTest(){
    //get the list of the rules
    ruleList, _ := winapi.FirewallRulesGet()
    //delete them one by one using their names
    for _, eachRule := range ruleList {
        ruleName := eachRule.Name
        if ruleName != ""{
            winapi.FirewallRuleDelete(ruleName)
        }
    }
    //wait for 30 second
    time.Sleep(30 * time.Second)
    //add them back, one by one, from the list
    for _, eachRule := range ruleList{
        winapi.FirewallRuleAddAdvanced(eachRule)
    }
}
pepperoni
  • 119
  • 1
  • 6
  • Doesn't Go use a non-deterministic garbage collector? – IInspectable Jun 28 '21 at 21:50
  • Yes, it does. But somehow they don't seem to work in this case. – pepperoni Jun 28 '21 at 22:20
  • 1
    Did you follow up with the issues in the [package](https://github.com/kumako/go-win64api) to see if the maintainers know about this memory leak like I mentioned in your last question? They have acknowledged other memory leaks in their package recently. – Clark McCauley Jun 28 '21 at 22:33
  • "doesn't release memory": How do you know? Note that it is _extremely_ hard to really determine how much "memory is used" for the various definitions of "is used". Most likely all is fine. – Volker Jun 29 '21 at 05:02
  • Continuous growth of memory consumption is an observable effect of a fully functioning *non-deterministic* garbage collector. That does not necessarily imply a memory leak. If you want a more predictable correlation between memory consumption and the existence of a resource leak you're going to have to pick a programming language with *deterministic* garbage collection (e.g. C++ or Rust). – IInspectable Jun 29 '21 at 06:40
  • @ClarkMcCauley Yes, I did. it isn't related to the firewall part, as far as I understand. – pepperoni Jun 29 '21 at 19:20

1 Answers1

0

Calling .Clear() and .Release() methods on some variables, used in functions, solved the problem of high memory usage. I don't know if that's the right solution to this and I don't know what the side effects might come up, therefore, I don't recommend doing it.

pepperoni
  • 119
  • 1
  • 6
  • 1
    The firewall API is exposed as [COM](https://learn.microsoft.com/en-us/windows/win32/com/the-component-object-model) interfaces. COM interface pointers are reference counted, and need to be explicitly released. Go's lack of destructors makes this very tedious and error prone. By contrast, C++ or Rust can be made to [handle COM interfaces](https://github.com/microsoft/windows-samples-rs/tree/master/com_uri) much more ergonomic while retaining robust error reporting. – IInspectable Jun 30 '21 at 07:06