我用我的应用程序运行callgrind,如下所示:
valgrind --tool=callgrind MyApplication
然后打电话:
callgrind_annotate --auto=yes ./callgrind.out.2489
我看到的输出如下:
768,097,560 PROGRAM TOTALS
--------------------------------------------------------------------------------
Ir file:function
--------------------------------------------------------------------------------
18,624,794 /build/buildd/eglibc-2.11.1/elf/dl-lookup.c:do_lookup_x
[/lib/ld-2.11.1.so]
18,149,492 /src/js/src/jsgc.cpp:JS_CallTracer'2
[/src/firefox-debug-objdir/js/src/libmozjs.so]
16,328,897 /src/layout/style/nsCSSDataBlock.cpp:nsCSSExpandedDataBlock::DoAssertInitialState()
[/src/firefox-debug-objdir/toolkit/library/libxul.so]
13,376,634 /build/buildd/eglibc-2.11.1/nptl/pthread_getspecific.c:pthread_getspecific
[/lib/libpthread-2.11.1.so]
13,005,623 /build/buildd/eglibc-2.11.1/malloc/malloc.c:_int_malloc
[/lib/libc-2.11.1.so]
10,404,453 ???:0x0000000000009190 [/usr/lib/libpangocairo-1.0.so.0.2800.0]
10,358,646 /src/xpcom/io/nsFastLoadFile.cpp:NS_AccumulateFastLoadChecksum(unsigned
int*, unsigned char const*, unsigned int, int)
[/src/firefox-debug-objdir/toolkit/library/libxul.so]
8,543,634 /src/js/src/jsscan.cpp:js_GetToken
[/src/firefox-debug-objdir/js/src/libmozjs.so]
7,451,273 /src/xpcom/typelib/xpt/src/xpt_arena.c:XPT_ArenaMalloc
[/src/firefox-debug-objdir/toolkit/library/libxul.so]
7,335,131 ???:g_type_check_instance_is_a [/usr/lib/libgobject-2.0.so.0.2400.0]
我有几个问题:
右边的数字是什么意思？这是否意味着它在调用右边的函数时花费了多长时间？如何判断调用该函数的次数,是否包括调用该函数调用的函数所花费的时间？
什么是???平均值？例如???:0x0000000000009190 [/usr/lib/libpangocairo-1.0.so.0.2800.0]
我一直在尝试调试崩溃的应用程序崩溃(即断言 *glibc检测到* free():无效指针:0x000000000070f0c0***)而我正在尝试对字符串进行简单的赋值.请注意,我正在使用gcc 4.2.4在Linux系统上进行编译,优化级别设置为-O2.使用-O0,应用程序不再崩溃.
例如
std::string abc;
abc = "testString";
但如果我按如下方式更改了代码,它就不会再崩溃了
std::string abc("testString");
所以我再次挠挠脑袋!但有趣的模式是,崩溃后来在应用程序中移动,AGAIN在另一个字符串.我发现应用程序在字符串赋值上不断崩溃是很奇怪的.典型的崩溃回溯看起来如下:
#0 0x00007f2c2663bfb5 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00007f2c2663bfb5 in raise () from /lib64/libc.so.6
#1 0x00007f2c2663dbc3 in abort () from /lib64/libc.so.6
#2 0x00000000004d8cb7 in people_streamingserver_sighandler (signum=6) at src/peoplestreamingserver.cpp:487
#3 <signal handler called>
#4 0x00007f2c2663bfb5 in raise () from /lib64/libc.so.6
#5 0x00007f2c2663dbc3 in abort () from /lib64/libc.so.6
#6 0x00007f2c26680ce0 in ?? () from /lib64/libc.so.6
#7 0x00007f2c270ca7a0 in std::string::assign (this=0x7f2c21bc8d20, __str=<value optimized out>)
at …是否有可能告诉valgrind忽略一些库？特别是glibc库..
实际问题:我有一些代码在正常执行中运行良好.没有泄漏等
当我尝试通过valgrind运行它时,我得到核心转储和程序重启/停止.
核心通常指向glibc函数(通常是fseek,mutex等).我知道不兼容的glibc/valgrind版本可能存在一些问题.
我尝试了各种valgrind版本和glibc版本,但没有运气.有什么建议？
关于std :: string中可能存在内存泄漏的许多valgrind警告我遇到了问题,如下所示:
120 bytes in 4 blocks are possibly lost in loss record 4,192 of 4,687
at 0x4A06819: operator new(unsigned long) (vg_replace_malloc.c:230)
by 0x383B89B8B0: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.8)
by 0x383B89C3B4: (within /usr/lib64/libstdc++.so.6.0.8)
by 0x383B89C4A9: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, unsigned long, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.8)
我在想:
Valgrinding使用openldap2的libldap的程序是一件苦差事,因为OpenSSL使用了未初始化的内存.存在一个--ignore-fn选项,但仅适用于Valgrind的massif子组件.memcheck是否有类似的东西可以排除出现某些功能的痕迹？
==13795== Use of uninitialised value of size 8 ==13795== at 0x6A9C8CF: ??? (in /lib64/libz.so.1.2.3) ==13795== by 0x6A9A63B: inflate (in /lib64/libz.so.1.2.3) ==13795== by 0x68035C1: ??? (in /lib64/libcrypto.so.1.0.0) ==13795== by 0x6802B9F: COMP_expand_block (in /lib64/libcrypto.so.1.0.0) ==13795== by 0x64ABBCD: ssl3_do_uncompress (in /lib64/libssl.so.1.0.0) ==13795== by 0x64ACA6F: ssl3_read_bytes (in /lib64/libssl.so.1.0.0) ==13795== by 0x64A9F2F: ??? (in /lib64/libssl.so.1.0.0) ==13795== by 0x56B3E61: ??? (in /usr/lib64/libldap-2.4.so.2.5.4) ==13795== by 0x5E4DB1B: ??? (in /usr/lib64/liblber-2.4.so.2.5.4) ==13795== by 0x5E4E96E: ber_int_sb_read (in /usr/lib64/liblber-2.4.so.2.5.4) ==13795== by 0x5E4B4A6: ber_get_next (in /usr/lib64/liblber-2.4.so.2.5.4) ==13795== by 0x568FB9E: …
所以...我正试图消除我的GTK + 3程序中的一些内存泄漏.我虽然回顾一些简单的例子来看看是否有一些我忘记的清理工具是个好主意,但文档中提供的hello_world程序也有漏洞.(下面的Valgrind输出).
这些泄漏是否可以接受？如果是这样,我应该使用其他一些应用来调试GTK程序吗？
==13717== Memcheck, a memory error detector
==13717== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==13717== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==13717== Command: ./a
==13717==
Hello World
==13717==
==13717== HEAP SUMMARY:
==13717== in use at exit: 1,578,162 bytes in 11,614 blocks
==13717== total heap usage: 45,699 allocs, 34,085 frees, 6,461,970 bytes allocated
==13717==
==13717== LEAK SUMMARY:
==13717== definitely lost: 2,560 bytes in 5 blocks
==13717== indirectly lost: 6,656 …我的应用程序中有一个非常简单的CUDA组件.Valgrind报告了许多泄漏和仍然可达,这些都与cudaMalloc调用有关.
这些泄漏真的存在吗？我呼吁cudaFree每一个人cudaMalloc.这个valgrind无法解释GPU内存分配吗？如果这些泄漏不是真的,我可以抑制它们并让valgrind只分析应用程序的非gpu部分吗？
extern "C"
unsigned int *gethash(int nodec, char *h_nodev, int len) {
unsigned int *h_out = (unsigned int *)malloc(sizeof(unsigned int) * nodec);
char *d_in;
unsigned int *d_out;
cudaMalloc((void**) &d_in, sizeof(char) * len * nodec);
cudaMalloc((void**) &d_out, sizeof(unsigned int) * nodec);
cudaMemcpy(d_in, h_nodev, sizeof(char) * len * nodec, cudaMemcpyHostToDevice);
int blocks = 1 + nodec / 512;
cube<<<blocks, 512>>>(d_out, d_in, nodec, len);
cudaMemcpy(h_out, d_out, sizeof(unsigned int) * nodec, cudaMemcpyDeviceToHost);
cudaFree(d_in);
cudaFree(d_out);
return h_out;
}
Valgrind输出的最后一位:
... …我正在从Learn C The Hard Way学习C语言.我正在练习6,虽然我可以使它工作,但valgrind会报告很多错误.
这是从文件中删除的最小程序ex6.c:
#include <stdio.h>
int main(int argc, char *argv[])
{
char initial = 'A';
float power = 2.345f;
printf("Character is %c.\n", initial);
printf("You have %f levels of power.\n", power);
return 0;
}
内容Makefile只是CFLAGS=-Wall -g.
我编译程序$ make ex6(没有编译器警告或错误).执行with $ ./ex6产生预期的输出.
当我运行程序时,$ valgrind ./ex6我得到了我无法解决的错误.这是完整的输出:
==69691== Memcheck, a memory error detector
==69691== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==69691== …我已经阅读了有关此参数的文档,但区别非常大!启用后,简单程序(见下文)的内存使用量约为7 GB,禁用时,报告的使用量约为160 KB.
top也显示大约7 GB,这有点证实了结果pages-as-heap=yes.
(我有一个理论,但我不相信它会解释这么大的差异,所以 - 请求一些帮助).
特别困扰我的是,大部分报告的内存使用情况都被使用std::string,而what?从未打印过(意思是 - 实际容量非常小).
我需要pages-as-heap=yes在分析我的应用程序时使用,我只是想知道如何避免"误报"
代码段:
#include <iostream>
#include <thread>
#include <vector>
#include <chrono>
void run()
{
while (true)
{
std::string s;
s += "aaaaa";
s += "aaaaaaaaaaaaaaa";
s += "bbbbbbbbbb";
s += "cccccccccccccccccccccccccccccccccccccccccccccccccc";
if (s.capacity() > 1024) std::cout << "what?" << std::endl;
std::this_thread::sleep_for(std::chrono::seconds(1));
}
}
int main()
{
std::vector<std::thread> workers;
for( unsigned i = 0; i < …我正在使用 Valgrind 来查找我的 C 程序的内存泄漏，尽管它看起来运行良好并显示分配和释放的内存。但是，我想知道它为什么会抛出这个错误以及它的后果是什么。
这是错误的片段：
==483== Memcheck, a memory error detector
==483== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==483== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==483== Command: ./main ../old\ projects
==483==
==483== error calling PR_SET_PTRACER, vgdb might block