英文:
COM call from go has its data collected by GC, zeroing used memory
问题
我有一个Go程序，执行一个WMI查询，然后将数据转换回Go语言的数据结构（使用这里的方法）。每隔一段时间，Go的垃圾回收机制会将一些看似随机的内存部分清零，导致严重的故障。
我正在尝试弄清楚到底是什么导致了这个问题，我相信下一步是了解在COM调用期间发生了什么。我目前的理解是：
- 从进程中使用WMI查询调用COM
- 操作系统执行查询并将结果写入由该进程拥有的某个内存位置
- 该位置从COM调用返回，然后我可以访问和序列化它
这大致是发生的情况吗？Windows如何选择内存位置，以避免覆盖现有数据？
英文:
I have a go program that executes a WMI query then converts the data back into go-land data structures (using the method here). Every so often, go's GC comes along and nukes some seemingly random parts of memory to 0s, causing horrible breakage.
I am trying to figure out what exactly is causing this problem, and the next step, I believe, is to understand what happens during the COM call. My current understanding is:
- call into COM with the WMI query from a process
- the OS executes the query and writes the results into some memory location owned by the process
- that location is returned from the COM call, which I can then access and serialize
Is this about what happens? How does Windows choose that memory location such that it doesn't overwrite existing data?
答案1
得分: 1
每个COM对象都使用AddRef()和Release()进行引用计数。也许你需要额外的AddRef()来延长其生命周期。
从示例代码中我看到有很多延迟的Release调用。这是可以的，因为我们希望在main函数结束时释放这些对象。在你的程序中，你可能希望更长时间地延迟Release（但是，我不了解Go语言或者defer的具体作用）。
英文:
Every COM object is reference counted with AddRef() and Release(). Perhaps you need an extra AddRef() to keep it around longer.
I see from the sample code that there are a lot of defered Release calls. This is fine because we want the objects released at the end of main. In your program you might want to put off Release even longer (but, I don't know go or exactly what defer does)
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论