- android - RelativeLayout 背景可绘制重叠内容
- android - 如何链接 cpufeatures lib 以获取 native android 库?
- java - OnItemClickListener 不起作用,但 OnLongItemClickListener 在自定义 ListView 中起作用
- java - Android 文件转字符串
我的项目存在内存泄漏。我可以找到它们,所以我清理了我的 main.cpp 文件,现在它看起来像这样:
int main()
{
return 0;
}
当我使用命令检查内存时:
valgrind --leak-check=full --show-leak-kinds=all ./MyProgram > log1.txt 2>&1
我遇到了这些错误:
==5219==
==5219== LEAK SUMMARY:
==5219== definitely lost: 0 bytes in 0 blocks
==5219== indirectly lost: 0 bytes in 0 blocks
==5219== possibly lost: 728 bytes in 18 blocks
==5219== still reachable: 44,676 bytes in 224 blocks
==5219== of which reachable via heuristic:
==5219== newarray : 832 bytes in 16 blocks
==5219== suppressed: 0 bytes in 0 blocks
==5219==
==5219== For counts of detected and suppressed errors, rerun with: -v
==5219== ERROR SUMMARY: 18 errors from 18 contexts (suppressed: 0 from 0)
一些错误是:
==5219== 2,048 bytes in 1 blocks are still reachable in loss record 240 of 242
==5219== at 0x402E2EC: realloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5219== by 0x5F7C151: g_realloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.4600.2)
==5219== by 0x5F06BCB: g_value_register_transform_func (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4600.2)
==5219== by 0x5F08D6A: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4600.2)
==5219== by 0x5ED9A2D: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4600.2)
==5219== by 0x400EDCF: call_init.part.0 (dl-init.c:72)
==5219== by 0x400EEDF: call_init (dl-init.c:30)
==5219== by 0x400EEDF: _dl_init (dl-init.c:120)
==5219== by 0x4000ACE: ??? (in /lib/i386-linux-gnu/ld-2.21.so)
==5219== 8 bytes in 1 blocks are possibly lost in loss record 95 of 242
==5219== at 0x402E0D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5219== by 0x5F7C0DA: g_malloc0 (in /lib/i386-linux-gnu/libglib-2.0.so.0.4600.2)
==5219== by 0x5EFC587: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4600.2)
==5219== by 0x5F011B8: g_type_register_fundamental (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4600.2)
==5219== by 0x5EE929E: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4600.2)
==5219== by 0x5ED9A1E: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4600.2)
==5219== by 0x400EDCF: call_init.part.0 (dl-init.c:72)
==5219== by 0x400EEDF: call_init (dl-init.c:30)
==5219== by 0x400EEDF: _dl_init (dl-init.c:120)
==5219== by 0x4000ACE: ??? (in /lib/i386-linux-gnu/ld-2.21.so)
完整日志文件:http://pastebin.com/DQxQtnzK
我该如何解决这个问题?我该怎么办?
最佳答案
以最少的编辑转录评论。
Add suppressions; they're 'leaks' caused by the startup code that can't be fixed by you and probably won't be fixed by the developers of the C++ runtime. This is an extensive problem on Mac OS X. There are typically many allocations and a few tens of kilobytes of memory that are allocated by the startup code. (Options include
--gen-suppressions=all
and--suppressions=suppressions-file
.)
本次征集评论:
FATAL: can't open suppressions file "suppressions-file"
哪个得到了还击(因为我发表评论时时间紧迫):
Read the manual. You use
--gen-suppressions=all
to generate the suppressions […]. Then edit the file (there's a placeholder where you're supposed to put an ID/name for each suppression entry). Then you can use the file in subsequent runs with--suppressions=name-you-created
. You may need--show-leak-kinds=all
, and maybe some others, too (-leak-check=full
, for example). Usevalgrind --help
, but be aware that the output is fairly extensive.
mincpp.cpp
)int main() { return 0; }
g++ -O3 -g -std=c++11 mincpp.cpp -o mincpp
(我通常会使用更多的警告选项,但是对于这段代码,真的没有必要。)
valgrind
$ valgrind mincpp
==69167== Memcheck, a memory error detector
==69167== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==69167== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==69167== Command: mincpp
==69167==
--69167-- UNKNOWN fcntl 97!
--69167-- UNKNOWN fcntl 97! (repeated 2 times)
--69167-- UNKNOWN fcntl 97! (repeated 4 times)
--69167-- UNKNOWN fcntl 97! (repeated 8 times)
--69167-- UNKNOWN fcntl 97! (repeated 16 times)
--69167-- UNKNOWN fcntl 97! (repeated 32 times)
==69167==
==69167== HEAP SUMMARY:
==69167== in use at exit: 22,195 bytes in 190 blocks
==69167== total heap usage: 255 allocs, 65 frees, 27,947 bytes allocated
==69167==
==69167== LEAK SUMMARY:
==69167== definitely lost: 4,120 bytes in 2 blocks
==69167== indirectly lost: 2,288 bytes in 6 blocks
==69167== possibly lost: 4,880 bytes in 45 blocks
==69167== still reachable: 2,344 bytes in 12 blocks
==69167== suppressed: 8,563 bytes in 125 blocks
==69167== Rerun with --leak-check=full to see details of leaked memory
==69167==
==69167== For counts of detected and suppressed errors, rerun with: -v
==69167== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
$
对于这样一个最小的程序来说,有很多泄漏!
未知的 fcntl
消息很烦人,但似乎“几乎无害”;我可能需要再次重建 valgrind
。
$ valgrind --gen-suppressions=all --leak-check=full --show-leak-kinds=all mincpp
==69211== Memcheck, a memory error detector
==69211== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==69211== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==69211== Command: mincpp
==69211==
--69211-- UNKNOWN fcntl 97!
--69211-- UNKNOWN fcntl 97! (repeated 2 times)
--69211-- UNKNOWN fcntl 97! (repeated 4 times)
--69211-- UNKNOWN fcntl 97! (repeated 8 times)
--69211-- UNKNOWN fcntl 97! (repeated 16 times)
--69211-- UNKNOWN fcntl 97! (repeated 32 times)
==69211==
==69211== HEAP SUMMARY:
==69211== in use at exit: 22,195 bytes in 190 blocks
==69211== total heap usage: 255 allocs, 65 frees, 27,947 bytes allocated
==69211==
==69211== 24 bytes in 1 blocks are still reachable in loss record 5 of 62
==69211== at 0x1000071FC: malloc_zone_malloc (vg_replace_malloc.c:304)
==69211== by 0x1005DC1E4: _read_images (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005E19EB: object_setClass (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005DABC7: gc_init (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005DA8C1: preopt_init (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005DA5CA: map_images_nolock (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005ECC6C: batchFinalizeOnTwoThreads(_malloc_zone_t*, void (*)(auto_zone_cursor*, void (*)(void*, void*), void*), auto_zone_cursor*, unsigned long) (in /usr/lib/libobjc.A.dylib)
==69211== by 0x7FFF5FC047CF: dyld::notifyBatchPartial(dyld_image_states, bool, char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)) (in /usr/lib/dyld)
==69211== by 0x7FFF5FC04516: dyld::registerImageStateBatchChangeHandler(dyld_image_states, char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)) (in /usr/lib/dyld)
==69211== by 0x10023789D: dyld_register_image_state_change_handler (in /usr/lib/system/libdyld.dylib)
==69211== by 0x1005D907B: _objc_init (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1001DFC93: _os_object_init (in /usr/lib/system/libdispatch.dylib)
==69211==
{
<insert_a_suppression_name_here>
Memcheck:Leak
match-leak-kinds: reachable
fun:malloc_zone_malloc
fun:_read_images
fun:object_setClass
fun:gc_init
fun:preopt_init
fun:map_images_nolock
fun:_ZL25batchFinalizeOnTwoThreadsP14_malloc_zone_tPFvP16auto_zone_cursorPFvPvS3_ES3_ES2_m
fun:_ZN4dyldL18notifyBatchPartialE17dyld_image_statesbPFPKcS0_jPK15dyld_image_infoE
fun:_ZN4dyld36registerImageStateBatchChangeHandlerE17dyld_image_statesPFPKcS0_jPK15dyld_image_infoE
fun:dyld_register_image_state_change_handler
fun:_objc_init
fun:_os_object_init
}
==69211== 24 bytes in 1 blocks are still reachable in loss record 6 of 62
==69211== at 0x1000071FC: malloc_zone_malloc (vg_replace_malloc.c:304)
==69211== by 0x1005DC1E4: _read_images (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005E19EB: object_setClass (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005DCC96: NXHashInsert (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005DB9B8: _read_images (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005DA5DA: map_images_nolock (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1005ECC6C: batchFinalizeOnTwoThreads(_malloc_zone_t*, void (*)(auto_zone_cursor*, void (*)(void*, void*), void*), auto_zone_cursor*, unsigned long) (in /usr/lib/libobjc.A.dylib)
==69211== by 0x7FFF5FC047CF: dyld::notifyBatchPartial(dyld_image_states, bool, char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)) (in /usr/lib/dyld)
==69211== by 0x7FFF5FC04516: dyld::registerImageStateBatchChangeHandler(dyld_image_states, char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)) (in /usr/lib/dyld)
==69211== by 0x10023789D: dyld_register_image_state_change_handler (in /usr/lib/system/libdyld.dylib)
==69211== by 0x1005D907B: _objc_init (in /usr/lib/libobjc.A.dylib)
==69211== by 0x1001DFC93: _os_object_init (in /usr/lib/system/libdispatch.dylib)
==69211==
{
<insert_a_suppression_name_here>
Memcheck:Leak
match-leak-kinds: reachable
fun:malloc_zone_malloc
fun:_read_images
fun:object_setClass
fun:NXHashInsert
fun:_read_images
fun:map_images_nolock
fun:_ZL25batchFinalizeOnTwoThreadsP14_malloc_zone_tPFvP16auto_zone_cursorPFvPvS3_ES3_ES2_m
fun:_ZN4dyldL18notifyBatchPartialE17dyld_image_statesbPFPKcS0_jPK15dyld_image_infoE
fun:_ZN4dyld36registerImageStateBatchChangeHandlerE17dyld_image_statesPFPKcS0_jPK15dyld_image_infoE
fun:dyld_register_image_state_change_handler
fun:_objc_init
fun:_os_object_init
}
…
==69211== LEAK SUMMARY:
==69211== definitely lost: 4,120 bytes in 2 blocks
==69211== indirectly lost: 2,288 bytes in 6 blocks
==69211== possibly lost: 4,880 bytes in 45 blocks
==69211== still reachable: 2,344 bytes in 12 blocks
==69211== suppressed: 8,563 bytes in 125 blocks
==69211==
==69211== For counts of detected and suppressed errors, rerun with: -v
==69211== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 12 from 12)
$
有时,我为一些数字 NN 添加 --num-callers=NN
,但在我的构建中默认值似乎是 12(在早期版本中更少) ,我认为),这就足够了。
min.suppressions
中生成抑制$ valgrind --gen-suppressions=all --leak-check=full --show-leak-kinds=all mincpp 2>./min.suppressions
$
min.suppressions
删除以==
和--
开头的行;剩下的就是压制。为抑制添加名称。最终结果类似于:
{
Mac-OSX-10.11.4-GCC-5.3.0-C++-Suppressions-001
Memcheck:Leak
match-leak-kinds: reachable
fun:malloc_zone_malloc
fun:_read_images
fun:object_setClass
fun:gc_init
fun:preopt_init
fun:map_images_nolock
fun:_ZL25batchFinalizeOnTwoThreadsP14_malloc_zone_tPFvP16auto_zone_cursorPFvPvS3_ES3_ES2_m
fun:_ZN4dyldL18notifyBatchPartialE17dyld_image_statesbPFPKcS0_jPK15dyld_image_infoE
fun:_ZN4dyld36registerImageStateBatchChangeHandlerE17dyld_image_statesPFPKcS0_jPK15dyld_image_infoE
fun:dyld_register_image_state_change_handler
fun:_objc_init
fun:_os_object_init
}
{
Mac-OSX-10.11.4-GCC-5.3.0-C++-Suppressions-002
Memcheck:Leak
match-leak-kinds: reachable
fun:malloc_zone_malloc
fun:_read_images
fun:object_setClass
fun:NXHashInsert
fun:_read_images
fun:map_images_nolock
fun:_ZL25batchFinalizeOnTwoThreadsP14_malloc_zone_tPFvP16auto_zone_cursorPFvPvS3_ES3_ES2_m
fun:_ZN4dyldL18notifyBatchPartialE17dyld_image_statesbPFPKcS0_jPK15dyld_image_infoE
fun:_ZN4dyld36registerImageStateBatchChangeHandlerE17dyld_image_statesPFPKcS0_jPK15dyld_image_infoE
fun:dyld_register_image_state_change_handler
fun:_objc_init
fun:_os_object_init
}
…
{
Mac-OSX-10.11.4-GCC-5.3.0-C++-Suppressions-021
Memcheck:Leak
match-leak-kinds: definite
fun:malloc_zone_memalign
fun:_ZL11addSubclassP10objc_classS0_
fun:_ZL12realizeClassP10objc_class
fun:_ZL12realizeClassP10objc_class
fun:_ZN4dyldL12notifySingleE17dyld_image_statesPK11ImageLoader
fun:_ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListERNS_15UninitedUpwardsE
fun:_ZN11ImageLoader19processInitializersERKNS_11LinkContextEjRNS_21InitializerTimingListERNS_15UninitedUpwardsE
fun:_ZN11ImageLoader19processInitializersERKNS_11LinkContextEjRNS_21InitializerTimingListERNS_15UninitedUpwardsE
fun:_ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE
fun:_ZN4dyld24initializeMainExecutableEv
fun:_ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_Pm
fun:_ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_Pm
}
--suppressions=./min.suppressions
重新运行$ valgrind --suppressions=./min.suppressions mincpp
==72028== Memcheck, a memory error detector
==72028== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==72028== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==72028== Command: mincpp
==72028==
--72028-- UNKNOWN fcntl 97!
--72028-- UNKNOWN fcntl 97! (repeated 2 times)
--72028-- UNKNOWN fcntl 97! (repeated 4 times)
--72028-- UNKNOWN fcntl 97! (repeated 8 times)
--72028-- UNKNOWN fcntl 97! (repeated 16 times)
--72028-- UNKNOWN fcntl 97! (repeated 32 times)
==72028==
==72028== HEAP SUMMARY:
==72028== in use at exit: 22,195 bytes in 190 blocks
==72028== total heap usage: 255 allocs, 65 frees, 27,947 bytes allocated
==72028==
==72028== LEAK SUMMARY:
==72028== definitely lost: 0 bytes in 0 blocks
==72028== indirectly lost: 0 bytes in 0 blocks
==72028== possibly lost: 0 bytes in 0 blocks
==72028== still reachable: 0 bytes in 0 blocks
==72028== suppressed: 22,195 bytes in 190 blocks
==72028==
==72028== For counts of detected and suppressed errors, rerun with: -v
==72028== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
$
这表明先前报告的错误现在已被抑制。
关于c++ - Valgrind 显示内存泄漏且 main 为空,不包含 header ,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/36893494/
我希望 valgrind 在发现第一个错误时停止并退出。 请勿推荐 --vgdb-error=1 :它不会退出 valgrind。您必须连接 gdb 并从那里终止。 --db-attach : 在最近
有人可以快速解释 Valgrind 的工作原理吗?一个例子:它如何知道内存何时被分配和释放? 最佳答案 Valgrind 基本上在“沙箱”中运行您的应用程序。在此沙箱中运行时,它能够插入自己的指令来进
我有一个因 SIGSEGV 而崩溃的应用程序。 --20183-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
我有一个因 SIGSEGV 而崩溃的应用程序。 --20183-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
我想使用 valgrind 检查长时间运行的进程是否存在内存泄漏。我怀疑我所追求的内存泄漏可能仅在执行几个小时后才会发生。我可以在 valgrind 下运行应用程序并获取 valgrind 日志,但这
我想用 valgrind 检查一个长时间运行的进程是否有内存泄漏。我怀疑我所追求的内存泄漏可能仅在执行数小时后才会发生。我可以在 valgrind 下运行应用程序并获得 valgrind 日志,但这样
如何在不通过 valgrind 命令选项启动它的情况下对每个 Process 实例执行 valgrind memcheck。 有没有办法将监控选项保存在进程中,而不是每次都使用 valgrind 命令
我使用了“--trace-children=yes”选项,我还使用了“--trace-children-skip=patt1,patt2,...”选项(过滤掉噪音过程)。但它对我来说仍然很慢,我的多进
我从 Valgrind 得到以下日志: MPK ==5263== 4 bytes in 1 blocks are still reachable in loss record 1 of 84 ==52
如何在 Valgrind 抑制文件中添加注释? 我需要为一个大型项目维护一个 Valgrind 抑制文件。我们从我们链接到的工具中过滤无法修复的错误。随着工具的新版本发布,此文件可能需要随着时间的推移
我有一个大程序要运行。使用 valgrind 需要几个小时才能运行。我听说有一些东西可以让我们为程序中的特定函数调用 valgrind。其余程序将正常执行(没有 valgrind env)。 任何人都
我可以用 valgrind 检测整数溢出缺陷吗?里面的哪个工具可以做到这一点? 最佳答案 Valgrind 没有可以检测整数溢出的工具。 您可能会使用 gcc 选项捕获这些错误: -ftrapv Th
我有一个简单的程序: int main(void) { const char sname[]="xxx"; sem_t *pSemaphor; if ((pSemaphor = sem_o
如何让 Valgrind 准确显示错误发生的位置?我编译了我的程序(通过 PuTTy 在 Windows 机器上通过 Linux 终端)添加了 -g 调试选项。 当我运行 Valgrind 时,我得到
或者最好是全部,而不仅仅是我的代码?我的程序使用 Gtk、Loudmouth 和其他一些东西,而这两个(以及它们背后的一些,libgcrypto、libssl)本身导致了如此多的错误,以至于我无法检测
我想尝试使用 valgrind 进行一些堆损坏检测。通过以下腐败“单元测试”: #include #include #include int main() { char * c = (ch
我看过类似的问题here ,但我的问题是我没有编辑 default.supp 文件的权限。例如,Valgrind 中是否有任何忽略所有抑制文件的命令行选项? 最佳答案 在 Valgrind 3.10.
我在一个运行无限循环的程序上使用 valgrind。 由于memcheck在程序结束后显示内存泄漏,但由于我的程序有无限循环,它永远不会结束。 那么有什么方法可以强制从 valgrind 时不时地转储
我一直在尝试使用 valgrind 查找一些可疑的内存错误。 在被分析的程序甚至到达我希望分析的点之前,它会因为对 mmap 的调用开始失败而退出。当它不在 valgrind 下时,这些调用会成功。
由于 OpenSSL 使用未初始化的内存,因此对使用 openldap2 的 libldap 的程序进行 Valgrind 是一件苦差事。存在一个 --ignore-fn选项,但仅适用于 Valgri
我是一名优秀的程序员,十分优秀!