3

我使用 valgrind 的地块跟踪程序退出前最后阶段的内存使用情况并发现

  • js::DateTimeInfo::updateTimeZoneAdjustment() (DateTime.cpp:19)

这是调用 localtime_r 并消耗一些内存。

16 ComputeLocalTime(time_t local, struct tm *ptm)
17 {
18 #ifdef HAVE_LOCALTIME_R
19     return localtime_r(&local, ptm);
20 #else
21     struct tm *otm = localtime(&local);
22     if (!otm)

valgrind 地块的最后一个快照的 ms_print

427711 --------------------------------------------------------------------------------
427712   n        time(i)         total(B)   useful-heap(B) extra-heap(B)    stacks(B)
427713 --------------------------------------------------------------------------------
427714  95 15,049,552,789              256              165            91            0
427715 64.45% (165B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
427716 ->36.72% (94B) 0x37AFA9EA6A: __tzfile_read (in /lib64/libc-2.12.so)
427717 | ->36.72% (94B) 0x37AFA9DC02: tzset_internal (in /lib64/libc-2.12.so)
427718 |   ->36.72% (94B) 0x37AFA9DD67: __tz_convert (in /lib64/libc-2.12.so)
427719 |     ->36.72% (94B) 0x4CAE552: js::DateTimeInfo::updateTimeZoneAdjustment() (DateTime.cpp:19)
427720 |       ->36.72% (94B) 0x4D814C9: JSRuntime::JSRuntime(JSUseHelperThreads) (jsapi.cpp:856)
427721 |         ->36.72% (94B) 0x4D8B71A: JS_NewRuntime(unsigned int, JSUseHelperThreads) (Utility.h:491)
427722 |           ->36.72% (94B) 0x40162A: main (js.cc:58)
427723 |
427724 ->15.62% (40B) 0x37AFA9D0D0: __tzstring (in /lib64/libc-2.12.so)
427725 | ->15.62% (40B) 0x37AFA9EF99: __tzfile_read (in /lib64/libc-2.12.so)
427726 |   ->15.62% (40B) 0x37AFA9DC02: tzset_internal (in /lib64/libc-2.12.so)
427727 |     ->15.62% (40B) 0x37AFA9DD67: __tz_convert (in /lib64/libc-2.12.so)
427728 |       ->15.62% (40B) 0x4CAE552: js::DateTimeInfo::updateTimeZoneAdjustment() (DateTime.cpp:19)
427729 |         ->15.62% (40B) 0x4D814C9: JSRuntime::JSRuntime(JSUseHelperThreads) (jsapi.cpp:856)
427730 |           ->15.62% (40B) 0x4D8B71A: JS_NewRuntime(unsigned int, JSUseHelperThreads) (Utility.h:491)
427731 |             ->15.62% (40B) 0x40162A: main (js.cc:58)
427732 |
427733 ->05.86% (15B) 0x37AFA81170: strdup (in /lib64/libc-2.12.so)
427734 | ->05.86% (15B) 0x37AFA9DBEF: tzset_internal (in /lib64/libc-2.12.so)
427735 |   ->05.86% (15B) 0x37AFA9DD67: __tz_convert (in /lib64/libc-2.12.so)
427736 |     ->05.86% (15B) 0x4CAE552: js::DateTimeInfo::updateTimeZoneAdjustment() (DateTime.cpp:19)
427737 |       ->05.86% (15B) 0x4D814C9: JSRuntime::JSRuntime(JSUseHelperThreads) (jsapi.cpp:856)
427738 |         ->05.86% (15B) 0x4D8B71A: JS_NewRuntime(unsigned int, JSUseHelperThreads) (Utility.h:491)
427739 |           ->05.86% (15B) 0x40162A: main (js.cc:58)
427740 |
427741 ->03.12% (8B) 0x4015C6: allocate() (js.cc:41)
427742 | ->03.12% (8B) 0x40187E: main (js.cc:114)
427743 |
427744 ->03.12% (8B) 0x4015E2: allocate() (js.cc:43)
427745 | ->03.12% (8B) 0x40187E: main (js.cc:114)
427746 |
427747 ->00.00% (0B) 0x4D8B3E8: JSRuntime::init(unsigned int) (Utility.h:154)
427748 | ->00.00% (0B) 0x4D8B73B: JS_NewRuntime(unsigned int, JSUseHelperThreads) (jsapi.cpp:1121)
427749 |   ->00.00% (0B) 0x40162A: main (js.cc:58)
427750 |
427751 ->00.00% (0B) 0x4D8B435: JSRuntime::init(unsigned int) (Utility.h:154)
427752 | ->00.00% (0B) 0x4D8B73B: JS_NewRuntime(unsigned int, JSUseHelperThreads) (jsapi.cpp:1121)
427753 |   ->00.00% (0B) 0x40162A: main (js.cc:58)

在我的程序退出之前有没有办法释放它？（据我了解，程序退出时它将被清除）

4

1 回答 1

2

为什么要localtime_r()分配内存？

C 运行时库中的日期/时间函数需要了解有关时区的各种信息，例如夏季夏令时何时开始和结束等。这些信息存储在所谓的时区文件中。

第一次调用某个相关的日期/时间函数时，需要加载、解析该文件并将其数据存储在某处，以便进一步调用这些函数不会再次产生相同的惩罚。您看到的分配与此有关。

那么它是内存泄漏吗？

该内存已分配，但在程序执行期间从未释放，因此可以认为是内存泄漏。但实际上这不是一个错误，因为它是库作者有意识的决定。

正如我上面所写的，数据被加载一次，并且（可能）从那以后在程序的其余运行时使用。它们只会在最后，在进程终止之前被释放。在 libc 中实际上有许多具有相同使用模式的结构。

所以他们认为与其一一进行所有分配，释放内存，而是将其留在那里，因为在下一毫秒，进程无论如何都会结束，内核无论如何都会回收所有分配的内存（而且速度更快，在它的时候，整个堆一次）。

那么有没有办法摆脱这个？

不是真的，有！但不适用于临时用户......正如Valgrind 文档所述：

glibc 作者意识到，当在退出时进行泄漏检查时，这种行为会导致泄漏检查器（例如 Valgrind）错误地报告 glibc 中的泄漏。为了避免这种情况，他们提供了一个__libc_freeres专门调用的例程，以使 glibc 释放它已分配的所有内存。

正如所料，处理时区文件的例程确实使用了这种“freeres”机制，例如time/tzfile.c：

libc_freeres_ptr (static time_t *transitions);

Valgrind 在结束之前调用此例程，因此如果您使用（默认）工具 memcheck 运行它，您不会看到任何这些“泄漏”。即使对于您的程序，它们也应该消失，它可能只是在它们发生时列出分配的地块，而不是在一切完成之后。

您可能会成功调用__libc_freeres自己，但它也可能会崩溃，因为 libc 在用户main()函数结束后仍会进行一些内部处理，并且您可能会过早释放其内部结构。

于 2014-05-08T22:54:12.637 回答