localtime_r 在程序退出前消耗一些内存

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

• 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)

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

Why is localtime_r()分配内存？

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

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

那么这是内存泄漏吗？

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

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

因此，他们认为，与其一一完成所有分配，释放内存，不如将其留在那里，因为在下一毫秒内，进程无论如何都会结束，并且内核无论如何都会回收所有分配的内存（而且速度更快，在此期间，整个堆立即）。

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

不是真的，有！但不适合临时用户......Valgrind 文档 http://valgrind.org/docs/manual/manual-core.html states:

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

正如预期的那样，处理时区文件的例程确实使用了这种“freeres”机制，例如time/tzfile.c http://sourceware.org/git/?p=glibc.git;a=blob;f=time/tzfile.c:

libc_freeres_ptr (static time_t *transitions);

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

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