问题标签 [boehm-gc]

众所周知，在多线程中使用 boehm-gc 需要GC_register_my_thread从GC_get_stack_base. 但它似乎不适用于 C++11 的线程库，例如std::thread......如何将 boehm-gc 与 C++11 的线程库一起使用？

（我用的是VS2013）

编辑：这是经过测试的代码。std::thread很好，但std::future不起作用（停止_CrtIsValidHeapPointer

编辑：这是堆栈跟踪的捕获（对不起，它不是英语，但我认为没关系，反正）

这是一条调试消息

在调试时，我发现错误发生在fu.get().

编辑：/MD（或/MDd）不会发生错误...

（我认为 GC 可能会触及库的指针（namespcae Concurrency），但这只是猜测；；）

我的问题与Java finalize 有关：即使有错误，我如何释放非 GC 资源。

1. 在大多数垃圾收集器finalize中并不总是调用？如果是这样，为什么不呢？并且是否有任何 GC 可以保证finalize在程序正常退出之前调用？

2. 我在一些项目中使用 boehm-gc。boehm-gc 是否保证finalize在程序正常退出之前调用？如果没有，有什么方法可以finalize在程序正常退出时调用？（可以这么说，在返回GC_gcollect之前打电话。）main

我有一些看起来像这样的代码：

我正在使用 Boehm 垃圾收集器。我希望 mumble 指向的数据是安全的，因为它仍然存在。但实际上，它是被收集和重复使用的。我检查了 GC_print_static_roots()：似乎整个 __mysection 部分不包含在任何根中。

（我确实找到了解决方案——但有人有更简单的想法吗？）

我正在尝试在我的 Mac 上安装交流垃圾收集器。我已经下载了所有必要的文件（git、automake 等）。我按照网站http://www.hboehm.info/gc/的说明进行操作。当我到达命令“automake --add-missing”时，我收到以下消息：

有人能帮我吗？我究竟做错了什么？谢谢！

我正在尝试在 Linux 中将 Boehm 垃圾收集器与 GLib 集成，但在一种情况下，我发现它没有释放内存：当我多次调用 g_strsplit 时，它会耗尽内存和段错误。垃圾收集器的自述文件警告说，它可能无法在动态库中找到指针，并且可能需要使用 GC_add_roots。

为了测试这一点，我将所有相关代码从 GLib 复制到我的源文件中，根本没有链接到 libglib-2.0.so。这消除了段错误，这告诉我这确实是问题所在。但是，没有关于如何使用 GC_add_roots 解决此问题的文档。有人能帮我吗？

这是导致内存泄漏的代码：

Boost.Coroutine 分配自己的调用堆栈。Boehm GC 是否将这些堆栈上的指针视为根，如果不是，我怎样才能做到这一点？在上下文切换到协程后，Boehm 终止程序。

我尝试在这个简单的代码中使用 libgc（BDW 垃圾收集器）。

请注意，该引用仅适用于假“列表”中的最后一个节点，因此，生活集只有两个最后一个节点。

但它不能停留在内存限制内：

$ gcc -O0 gc.c -lgc -o gc

$ GC_MAXIMUM_HEAP_SIZE=100000000 ./gc

我做错了什么？Ubuntu 15.04 x86_64 gcc 4.9.2 libgc 7.2d-6.4

更新：我刚刚从https://github.com/ivmai/bdwgc编译了主干版本，它看起来工作正常。因此，错误仅存在于 7.2d 或打包到 Ubuntu 的版本中。

更新：从源代码编译的 libgc 7.2f 也可以正常工作。所以这只是 Ubuntu 和 Debian 的版本问题。

我正在尝试将 glib 中的一些函数绑定到 Crystal 中。我已经这样做了，它的工作原理：

但是它引入了内存泄漏：使用 g_* 函数创建的对象永远不会被垃圾收集。

是否有可能使 glib 在 Crystal 中与 Boehm GC 一起玩得很好？受PCRE的启发，我试过这个：

希望覆盖/重新定义g_malloc和g_free功能。但它不起作用：它因分段错误而失败。

任何想法如何让 glib 与 GC 一起玩？我发现了某种相关的问题，但它没有帮助我：垃圾收集与 glib？

提前感谢。

我有一个使用 Boehm GC 一段时间的大型 C 项目；它是从头开始构建的，从一开始就使用 Boehm GC，它的类型分配行为是众所周知的。

目前，它使用GC_MALLOC()and GC_MALLOC_ATOMIC()，并且它具有可接受的（可容忍的）性能。但是因为它的所有类型都是众所周知的，并且该项目通常与 C 生态系统的其余部分隔离（它不链接 libc 之外的任何内容），所以将项目切换为主要使用GC_malloc_explicitly_typed(). 该项目的许多类型混合匹配原始值和指针，因此理论上，这应该通过允许收集器在通过它分配的所有类型上精确而不是保守来提高收集期间的性能。（这可能不会有很大的性能提升，但我仍然希望对垃圾收集器尽可能好。）

也就是说，gc_typed.h顶部有关于使用的各种警告消息GC_malloc_explicitly_typed()：

和这个：

我真的不相信这些对我来说都是问题，而且我的代码对性能至关重要，而且收集器在我的一些分析中确实很热门。我认为我不需要GC_DEBUG——至少，我从来没有觉得需要调试堆。我对GC_make_descriptor()需要分配的每种类型进行调用都没有问题，并且在程序启动时以可预测的常数次数调用该函数也没有问题。

看起来我的代码是 using 的完美候选者GC_malloc_explicitly_typed()，但这些警告消息的数量和范围仍然让我犹豫不决，它们似乎暗示该explicitly_typed函数将在某个时候被删除以支持“更好”的界面。所以我的问题很简单：

有没有人GC_malloc_explicitly_typed()发现使用它有任何未说明或不明显的缺点？

Boehm 的保守垃圾收集器非常有用（例如Bigloo正在使用它，Guile正在使用类似的东西，等等......），尤其是在 Linux 上（这是我唯一关心的操作系统；我正在使用 Debian/Sid/x86 -64 如果这很重要，并且libgc-dev包是版本1:7.4.2-8，所以 Boehm GC 是 7.4.2）。

但是，Boehm 的 GC需要了解使用它的每个线程。它的gc_pthreads_redirects.h（或多或少内部）头文件被重新定义pthread_create为

实际上，Boehm 的 GC 需要的是在新线程调用堆栈的早期调用GC_register_my_threadGC_pthread_create （并且正在这样做）。

过去，Glib (2.46) 提供了一种重新定义内存分配的方法，该方法已struct GMemVTable被弃用 且不能再使用（我的 Debianlibglib2.02.0-dev软件包是 version 2.50.3-2）。有一个g_mem_gc_friendly全局布尔值，但在查看 Glib 源代码时，它只是在释放内存区域之前清除它们。

最近的 GTK3（我的libgtk-3-dev 包有版本）正在使用（间接）通过Glib 线程函数3.22.11-1创建线程（可能与 Dbus 相关，也可能与 GtkTextView 相关）。并且没有办法（除了通过修补源代码）被通知该线程的创建。我担心我会安装（例如使用）的任何 GTK 回调可能会从这些线程中调用。或者，如果我使用一些可能使用（或访问）某些-ed 缓冲区的方法对 GTK 小部件进行子类化，则可能会发生灾难。pthread_createg_signal_connectGC_malloc

另一方面，GTK 中有一个严格的编码规则，即所有 GTK 操作都应该只发生在主线程中。引用Gdk3 线程页面：

然而，GTK+不是线程安全的。您应该只使用线程中的 GTK+ 和 GDKgtk_init()并被gtk_main()调用。这通常被称为“主线程”。

如果我自己遵循这条规则，我确信没有内部 GTK 代码会从某个非主线程调用我的回调（使用 Boehm GC）？

我的直觉是，如果GC_allocGTK 内部（不是直接由我的代码）从主线程外部调用，则会发生灾难（因为这些 GTK 内部线程尚未以 开始GC_pthread_create；可能会调用我的一些代码，例如因为我正在继承一些现有的 GTK 小部件，或者因为我连接了一些 GTK 信号，即使我自己没有在主线程之外使用 GTK 和 Boehm GC 编写代码。）。

关键是 Boehm 的 GC 需要扫描可能使用它的每个线程中的每个堆栈。

FWIW，我在 GTK bugzilla 上报告了一个可能的错误#780815 。

一个典型的例子gtk+-3.22.11/examples/application9/来自 GTK-3.22.11 tarball。由via非常间接地pthread_create 调用g_application_rung_bus_get_sync