I have a c++ project which I've been using for a while (on a stable build now), recently I had a new debian setup a few days ago and I've set everything up. I set up ffmpeg like I always do and some of my other projects which also depend on ffmpeg seems to be working fine. I've checked ffplay and it works, along with the many different input videos I'm trying with. However, when I try to run the project mentioned, I get various weird behaviours on different videos. For example: some of them say moov atom not found, some of them throw a seg-fault, some of them just crashes the program without any warnings or segfaults or anything.
Like I've said this is a fresh new debian build and the project is working just fine on other computers including this computer before I got a fresh debian (it was debian before aswell).
Here is how I set up ffmpeg:
Pull ffmpeg from it's github page and checkout to latest stable build branch (5.1)
Sudo install dependencies like libx264-dev and nasm and a few more
run ./configure --extra-libs="-lpthread -lm" --ld="g++" --disable-static --enable-shared --enable-gpl --enable-gnutls --enable-libfreetype --enable-nonfree --enable-libx264 --enable-opencl --enable-opengl
run make, then sudo make install and finally sudo ldconfig.
About the errors:
If I'm not getting a seg fault but the program just crashes without any errors, when I run valgrind it doesn't say anything (on .mp4 and .avi files mostly). So I ran with the --leak-check=full flag and get the following output (cropped some of it):
...
==220709== 132 bytes in 1 blocks are possibly lost in loss record 323 of 386
==220709== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==220709== by 0x8C67DA0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.8)
==220709== by 0x8BE51E4: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709== by 0x8BE8589: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709== by 0x8BCB531: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709== by 0x8BC49C7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709== by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709== by 0x40100E8: call_init (dl-init.c:30)
==220709== by 0x40100E8: _dl_init (dl-init.c:119)
==220709== by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==220709==
==220709== 148 bytes in 1 blocks are possibly lost in loss record 327 of 386
==220709== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==220709== by 0x8C67DA0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.8)
==220709== by 0x8BE4FEA: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709== by 0x8BE8589: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709== by 0x8BD4B2B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709== by 0x8BC49D1: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709== by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709== by 0x40100E8: call_init (dl-init.c:30)
==220709== by 0x40100E8: _dl_init (dl-init.c:119)
==220709== by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==220709==
==220709== 148 bytes in 1 blocks are possibly lost in loss record 328 of 386
==220709== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==220709== by 0x8C67DA0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.8)
==220709== by 0x8BE4FEA: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709== by 0x8BE8589: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709== by 0x8BCFBF3: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709== by 0x8BC49D6: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709== by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709== by 0x40100E8: call_init (dl-init.c:30)
==220709== by 0x40100E8: _dl_init (dl-init.c:119)
==220709== by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==220709==
==220709== 184 bytes in 1 blocks are possibly lost in loss record 339 of 386
==220709== at 0x483AD7B: realloc (vg_replace_malloc.c:834)
==220709== by 0x8C67DE7: g_realloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.8)
==220709== by 0x8BE3B76: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709== by 0x8BE87AC: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709== by 0x8BD67DE: g_param_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709== by 0x8BD915A: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709== by 0x8BC49DB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709== by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709== by 0x40100E8: call_init (dl-init.c:30)
==220709== by 0x40100E8: _dl_init (dl-init.c:119)
==220709== by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==220709==
==220709== 1,502 (352 direct, 1,150 indirect) bytes in 1 blocks are definitely lost in loss record 368 of 386
==220709== at 0x4838DEF: operator new(unsigned long) (vg_replace_malloc.c:342)
==220709== by 0x1D19819D: ???
==220709== by 0x1D177ED3: ???
==220709== by 0x1D18AAC9: ???
==220709== by 0x1D1683B0: ???
==220709== by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709== by 0x40100E8: call_init (dl-init.c:30)
==220709== by 0x40100E8: _dl_init (dl-init.c:119)
==220709== by 0x4F82AEC: _dl_catch_exception (dl-error-skeleton.c:182)
==220709== by 0x4014057: dl_open_worker (dl-open.c:758)
==220709== by 0x4F82A8F: _dl_catch_exception (dl-error-skeleton.c:208)
==220709== by 0x40138F9: _dl_open (dl-open.c:837)
==220709== by 0x8D9B257: dlopen_doit (dlopen.c:66)
==220709==
==220709== LEAK SUMMARY:
==220709== definitely lost: 384 bytes in 3 blocks
==220709== indirectly lost: 1,230 bytes in 20 blocks
==220709== possibly lost: 1,352 bytes in 18 blocks
==220709== still reachable: 189,789 bytes in 1,437 blocks
==220709== of which reachable via heuristic:
==220709== stdstring : 1,845 bytes in 46 blocks
==220709== newarray : 1,536 bytes in 16 blocks
==220709== suppressed: 12 bytes in 1 blocks
==220709== Reachable blocks (those to which a pointer was found) are not shown.
==220709== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==220709==
==220709== For lists of detected and suppressed errors, rerun with: -s
==220709== ERROR SUMMARY: 21 errors from 21 contexts (suppressed: 0 from 0)
As of writing this I've failed to replicate the error I got before about when I get a seg fault. As of now whether or not I get a segfault or not I'm getting the same output as above.
What could be the reason for this? Am I setting ffmpeg wrong?
Related
Overview
I have a C program using libpq to send PostgreSQL queries to a database.
Despite getting the desired output I'm experiencing a memory leak related to PQconnectdb() that I cannot seem to resolve using the documentation.
The only related thing I could find is this thread that suggests its related to openSSL but I could not resolve it with their suggestion.
Test File
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <libpq-fe.h>
void exit_nicely(PGconn *conn){
fprintf(stderr, "%s\n", PQerrorMessage(conn));
PQfinish(conn);
exit(1);
}
int main(int argc, char **argv){
// Open connection with database.
char conninfo[100] = "<HOST NAME>";
strcat(conninfo, "<USERNAME>");
strcat(conninfo, "<PASSWORD>");
PGconn *conn = PQconnectdb(conninfo);
(PQstatus(conn) == CONNECTION_OK) ? printf("Connected\n") : exit_nicely(conn);
// Send query, receive result.
PGresult* res = PQexec(conn, "SELECT VERSION();");
// Error checking.
if(PQresultStatus(res) != PGRES_TUPLES_OK){
fprintf(stderr, "ERROR%d: %s\n", PQresultStatus(res), PQresStatus(PQresultStatus(res)));
PQclear(res);
exit_nicely(conn);
}
// Extract data from result.
printf("Attribute1 name: %-15s\n", PQfname(res, 0));
printf("Attribute1, row1 value: %-15s\n", PQgetvalue(res, 0, 0));
PQclear(res);
PQfinish(conn);
return 0;
}
Output
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all -s ./test
==7827== Memcheck, a memory error detector
==7827== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==7827== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==7827== Command: ./test
==7827==
Connected
Attribute1 name: version
Attribute1, row1 value: PostgreSQL 14.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit
==7827==
==7827== HEAP SUMMARY:
==7827== in use at exit: 153 bytes in 4 blocks
==7827== total heap usage: 33,923 allocs, 33,919 frees, 3,248,431 bytes allocated
==7827==
==7827== 8 bytes in 1 blocks are still reachable in loss record 1 of 4
==7827== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==7827== by 0x4FEC4E9: ??? (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x50038A6: ??? (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x50043D9: ??? (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x4FDE532: gss_add_cred_from (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x4FE1187: gss_acquire_cred_from (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x4FE13C9: gss_acquire_cred (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x4878B73: PQconnectPoll (in /usr/lib/x86_64-linux-gnu/libpq.so.5.15)
==7827== by 0x487A2EF: ??? (in /usr/lib/x86_64-linux-gnu/libpq.so.5.15)
==7827== by 0x487A3E7: PQconnectdb (in /usr/lib/x86_64-linux-gnu/libpq.so.5.15)
==7827== by 0x10949F: main (in /home/shawn/Lab4/test)
==7827==
==7827== 24 bytes in 1 blocks are still reachable in loss record 2 of 4
==7827== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==7827== by 0x4FEC494: ??? (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x50038A6: ??? (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x50043D9: ??? (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x4FDE532: gss_add_cred_from (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x4FE1187: gss_acquire_cred_from (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x4FE13C9: gss_acquire_cred (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x4878B73: PQconnectPoll (in /usr/lib/x86_64-linux-gnu/libpq.so.5.15)
==7827== by 0x487A2EF: ??? (in /usr/lib/x86_64-linux-gnu/libpq.so.5.15)
==7827== by 0x487A3E7: PQconnectdb (in /usr/lib/x86_64-linux-gnu/libpq.so.5.15)
==7827== by 0x10949F: main (in /home/shawn/Lab4/test)
==7827==
==7827== 48 bytes in 1 blocks are still reachable in loss record 3 of 4
==7827== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==7827== by 0x517F6C4: krb5int_setspecific (in /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1)
==7827== by 0x4FEC505: ??? (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x50038A6: ??? (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x50043D9: ??? (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x4FDE532: gss_add_cred_from (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x4FE1187: gss_acquire_cred_from (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x4FE13C9: gss_acquire_cred (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x4878B73: PQconnectPoll (in /usr/lib/x86_64-linux-gnu/libpq.so.5.15)
==7827== by 0x487A2EF: ??? (in /usr/lib/x86_64-linux-gnu/libpq.so.5.15)
==7827== by 0x487A3E7: PQconnectdb (in /usr/lib/x86_64-linux-gnu/libpq.so.5.15)
==7827== by 0x10949F: main (in /home/shawn/Lab4/test)
==7827==
==7827== 73 bytes in 1 blocks are still reachable in loss record 4 of 4
==7827== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==7827== by 0x496060E: strdup (strdup.c:42)
==7827== by 0x4FEC456: ??? (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x50038A6: ??? (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x50043D9: ??? (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x4FDE532: gss_add_cred_from (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x4FE1187: gss_acquire_cred_from (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x5006629: ??? (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x5006749: ??? (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x4FDE532: gss_add_cred_from (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x4FE1187: gss_acquire_cred_from (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827== by 0x4FE13C9: gss_acquire_cred (in /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2)
==7827==
==7827== LEAK SUMMARY:
==7827== definitely lost: 0 bytes in 0 blocks
==7827== indirectly lost: 0 bytes in 0 blocks
==7827== possibly lost: 0 bytes in 0 blocks
==7827== still reachable: 153 bytes in 4 blocks
==7827== suppressed: 0 bytes in 0 blocks
==7827==
==7827== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 months ago.
Improve this question
So currently I am writing a XMLParser into a Tree and its working fine but the problem is its using too much Memmory and when I am trying to run it with a 4GB XML file it is not working due to lack of memmory.
So what im doing is going through first converting the XML File into a char* and then Parsing throught it and using malloc to allocate memmory for each Node structure.
When exactly am I supposed to Free() these nodes ? Am I even supposed to do that ? I just dont understand when exactly am I supposed to free stuff basically.
I am getting Valgrind errors
==3002== HEAP SUMMARY:
==3002== in use at exit: 8,995 bytes in 423 blocks
==3002== total heap usage: 427 allocs, 137 frees, 24,691 bytes allocated
==3002==
==3002== 19 bytes in 1 blocks are indirectly lost in loss record 1 of 8
==3002== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3002== by 0x491460E: strdup (strdup.c:42)
==3002== by 0x109B9D: parse (main.c:223)
==3002== by 0x10A06B: main (main.c:333)
==3002==
==3002== 48 bytes in 1 blocks are indirectly lost in loss record 2 of 8
==3002== at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3002== by 0x10934B: new_node (main.c:9)
==3002== by 0x10A054: main (main.c:332)
==3002==
==3002== 206 bytes in 32 blocks are definitely lost in loss record 3 of 8
==3002== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3002== by 0x491460E: strdup (strdup.c:42)
==3002== by 0x1096E9: parse (main.c:108)
==3002== by 0x10A06B: main (main.c:333)
==3002==
==3002== 551 bytes in 101 blocks are indirectly lost in loss record 4 of 8
==3002== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3002== by 0x491460E: strdup (strdup.c:42)
==3002== by 0x1096E9: parse (main.c:108)
==3002== by 0x10A06B: main (main.c:333)
==3002==
==3002== 608 bytes in 19 blocks are indirectly lost in loss record 5 of 8
==3002== at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3002== by 0x109648: add_attribute (main.c:85)
==3002== by 0x109DC4: parse (main.c:275)
==3002== by 0x10A06B: main (main.c:333)
==3002==
==3002== 1,083 bytes in 134 blocks are indirectly lost in loss record 6 of 8
==3002== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3002== by 0x491460E: strdup (strdup.c:42)
==3002== by 0x109D13: parse (main.c:255)
==3002== by 0x10A06B: main (main.c:333)
==3002==
==3002== 6,432 bytes in 134 blocks are indirectly lost in loss record 7 of 8
==3002== at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3002== by 0x10934B: new_node (main.c:9)
==3002== by 0x109C3A: parse (main.c:238)
==3002== by 0x10A06B: main (main.c:333)
==3002==
==3002== 8,789 (48 direct, 8,741 indirect) bytes in 1 blocks are definitely lost in loss record 8 of 8
==3002== at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3002== by 0x10934B: new_node (main.c:9)
==3002== by 0x109B7E: parse (main.c:221)
==3002== by 0x10A06B: main (main.c:333)
==3002==
==3002== LEAK SUMMARY:
==3002== definitely lost: 254 bytes in 33 blocks
==3002== indirectly lost: 8,741 bytes in 390 blocks
==3002== possibly lost: 0 bytes in 0 blocks
==3002== still reachable: 0 bytes in 0 blocks
==3002== suppressed: 0 bytes in 0 blocks
==3002==
==3002== For lists of detected and suppressed errors, rerun with: -s
My thought process was that If I free these nodes then the Tree is destroyed in the proccess. Or is it because I am allocating EXTRA stuff that is not needed?
TY
When exactly am I supposed to Free() these nodes ? Am I even supposed to do that ? I just dont understand when exactly am I supposed to free stuff basically. I am getting Valgrind errors
After using either malloc(), calloc() or realloc(), a pointer will be returned to you to some memory on the heap (assuming no error occurred).
You should free() the memory using the pointer returned from these functions once you no longer need the memory that was allocated.
Example:
struct node* new_node = malloc(sizeof(struct node));
if (new_node == NULL) {
// malloc() failed
}
// do stuff with new_node
free(new_node); // no longer need new_node
I've been getting this error whenever i run a full valgrind memory leak check and I really can't tell where the source of this error is. My code is running and appears to be correct but i've been getting this error since. Any advice would be much appreciated, thank you!
==2312== HEAP SUMMARY:
==2312== in use at exit: 26,325 bytes in 190 blocks
==2312== total heap usage: 20,531 allocs, 20,341 frees, 197,089 bytes allocated
==2312==
==2312== Searching for pointers to 190 not-freed blocks
==2312== Checked 9,805,752 bytes
==2312==
==2312== 272 (80 direct, 192 indirect) bytes in 1 blocks are definitely lost in loss record 53 of 67
==2312== at 0x100009EBB: malloc (in /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==2312== by 0x1001C44A2: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==2312== by 0x1001C4DEB: __d2b_D2A (in /usr/lib/system/libsystem_c.dylib)
==2312== by 0x1001C1443: __dtoa (in /usr/lib/system/libsystem_c.dylib)
==2312== by 0x1001EA07A: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==2312== by 0x10021335C: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==2312== by 0x1001E901D: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==2312== by 0x1001E6EB7: printf (in /usr/lib/system/libsystem_c.dylib)
==2312== by 0x100001B02: main (in ./tldmonitor)
==2312==
==2312== LEAK SUMMARY:
==2312== definitely lost: 80 bytes in 1 blocks
==2312== indirectly lost: 192 bytes in 5 blocks
==2312== possibly lost: 0 bytes in 0 blocks
==2312== still reachable: 0 bytes in 0 blocks
==2312== suppressed: 26,053 bytes in 184 blocks
==2312==
==2312== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 16 from 16)
--2312--
--2312-- used_suppression: 1 OSX1011:21-Leak /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/default.supp:944 suppressed: 4,096 bytes in 1 blocks
--2312-- used_suppression: 1 OSX1011:15-Leak /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/default.supp:886 suppressed: 4,096 bytes in 1 blocks
--2312-- used_suppression: 10 OSX1011:17-Leak /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/default.supp:906 suppressed: 3,392 bytes in 55 blocks
--2312-- used_suppression: 3 OSX1011:16-Leak /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/default.supp:897 suppressed: 2,816 bytes in 44 blocks
--2312-- used_suppression: 2 OSX1011:4-Leak /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/default.supp:778 suppressed: 4,152 bytes in 2 blocks
--2312-- used_suppression: 2 OSX1011:19-Leak /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/default.supp:924 suppressed: 2,592 bytes in 2 blocks
--2312-- used_suppression: 7 OSX1011:7-Leak /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/default.supp:808 suppressed: 1,680 bytes in 22 blocks
--2312-- used_suppression: 11 OSX1011:18-Leak /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/default.supp:915 suppressed: 2,312 bytes in 11 blocks
--2312-- used_suppression: 20 OSX1011:10-Leak /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/default.supp:839 suppressed: 2,461 bytes in 39 blocks
--2312-- used_suppression: 2 OSX1011:8-Leak /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/default.supp:819 suppressed: 520 bytes in 2 blocks
--2312-- used_suppression: 2 OSX1011:20-Leak /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/default.supp:934 suppressed: 224 bytes in 5 blocks
==2312==
==2312== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 16 from 16)
After i generate a suppression block:
==2317== HEAP SUMMARY:
==2317== in use at exit: 26,325 bytes in 190 blocks
==2317== total heap usage: 20,531 allocs, 20,341 frees, 197,089 bytes allocated
==2317==
==2317== Searching for pointers to 190 not-freed blocks
==2317== Checked 9,805,752 bytes
==2317==
==2317== 272 (80 direct, 192 indirect) bytes in 1 blocks are definitely lost in loss record 53 of 67
==2317== at 0x100009EBB: malloc (in /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==2317== by 0x1001C44A2: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==2317== by 0x1001C4DEB: __d2b_D2A (in /usr/lib/system/libsystem_c.dylib)
==2317== by 0x1001C1443: __dtoa (in /usr/lib/system/libsystem_c.dylib)
==2317== by 0x1001EA07A: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==2317== by 0x10021335C: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==2317== by 0x1001E901D: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==2317== by 0x1001E6EB7: printf (in /usr/lib/system/libsystem_c.dylib)
==2317== by 0x100001B02: main (in ./tldmonitor)
==2317==
==2317==
Turns out it was a false leak, tested my code on a linux virtual machine and no errors. Thanks.
The following code compiles correctly and valgrind reports no leaks:
# include <libxml/encoding.h>
# include <libxml/xmlwriter.h>
int main(void) {
xmlTextWriterPtr XMLWriter = xmlNewTextWriterFilename("example.xml", 0);
xmlTextWriterStartDocument(XMLWriter, NULL, NULL, NULL);
xmlTextWriterEndDocument(XMLWriter);
xmlFreeTextWriter(XMLWriter);
xmlCleanupParser();
return 0;
}
-----------------------------------------
==26059== HEAP SUMMARY:
==26059== in use at exit: 0 bytes in 0 blocks
==26059== total heap usage: 16 allocs, 16 frees, 4,774 bytes allocated
==26059==
==26059== All heap blocks were freed -- no leaks are possible
Once the encoding is specified in the xmlNewTextWriterFilename call, however, hilary ensues:
# include <libxml/encoding.h>
# include <libxml/xmlwriter.h>
int main(void) {
xmlTextWriterPtr XMLWriter = xmlNewTextWriterFilename("example.xml", 0);
xmlTextWriterStartDocument(XMLWriter, NULL, "UTF-8", NULL);
xmlTextWriterEndDocument(XMLWriter);
xmlFreeTextWriter(XMLWriter);
xmlCleanupParser();
return 0;
}
-----------------------------------------
==26082== HEAP SUMMARY:
==26082== in use at exit: 422 bytes in 17 blocks
==26082== total heap usage: 36 allocs, 19 frees, 9,224 bytes allocated
==26082==
==26082== 5 bytes in 1 blocks are still reachable in loss record 1 of 17
==26082== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082== by 0x40EC23B: xmlStrndup (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x494942FF: ???
==26082==
==26082== 6 bytes in 1 blocks are still reachable in loss record 2 of 17
==26082== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082== by 0x40EC23B: xmlStrndup (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x37: ???
==26082==
==26082== 6 bytes in 1 blocks are still reachable in loss record 3 of 17
==26082== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082== by 0x40EC23B: xmlStrndup (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x39350048: ???
==26082==
==26082== 7 bytes in 1 blocks are still reachable in loss record 4 of 17
==26082== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082== by 0x40EC23B: xmlStrndup (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x45003630: ???
==26082==
==26082== 9 bytes in 1 blocks are still reachable in loss record 5 of 17
==26082== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082== by 0x40EC23B: xmlStrndup (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x454C3630: ???
==26082==
==26082== 9 bytes in 1 blocks are still reachable in loss record 6 of 17
==26082== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082== by 0x40EC23B: xmlStrndup (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x45423630: ???
==26082==
==26082== 9 bytes in 1 blocks are still reachable in loss record 7 of 17
==26082== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082== by 0x40EC23B: xmlStrndup (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x49494352: ???
==26082==
==26082== 11 bytes in 1 blocks are still reachable in loss record 8 of 17
==26082== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082== by 0x40EC23B: xmlStrndup (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x39353837: ???
==26082==
==26082== 20 bytes in 1 blocks are still reachable in loss record 9 of 17
==26082== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082== by 0x406E9D1: xmlNewCharEncodingHandler (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x406EB28: xmlInitCharEncodingHandlers (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x41B54D2: (below main) (libc-start.c:226)
==26082==
==26082== 20 bytes in 1 blocks are still reachable in loss record 10 of 17
==26082== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082== by 0x406E9D1: xmlNewCharEncodingHandler (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x406EB44: xmlInitCharEncodingHandlers (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x41B54D2: (below main) (libc-start.c:226)
==26082==
==26082== 20 bytes in 1 blocks are still reachable in loss record 11 of 17
==26082== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082== by 0x406E9D1: xmlNewCharEncodingHandler (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x406EB6C: xmlInitCharEncodingHandlers (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x41B54D2: (below main) (libc-start.c:226)
==26082==
==26082== 20 bytes in 1 blocks are still reachable in loss record 12 of 17
==26082== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082== by 0x406E9D1: xmlNewCharEncodingHandler (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x406EB94: xmlInitCharEncodingHandlers (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x41B54D2: (below main) (libc-start.c:226)
==26082==
==26082== 20 bytes in 1 blocks are still reachable in loss record 13 of 17
==26082== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082== by 0x406E9D1: xmlNewCharEncodingHandler (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x406EBB6: xmlInitCharEncodingHandlers (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x41B54D2: (below main) (libc-start.c:226)
==26082==
==26082== 20 bytes in 1 blocks are still reachable in loss record 14 of 17
==26082== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082== by 0x406E9D1: xmlNewCharEncodingHandler (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x406EBCC: xmlInitCharEncodingHandlers (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x41B54D2: (below main) (libc-start.c:226)
==26082==
==26082== 20 bytes in 1 blocks are still reachable in loss record 15 of 17
==26082== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082== by 0x406E9D1: xmlNewCharEncodingHandler (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x406EBE2: xmlInitCharEncodingHandlers (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x41B54D2: (below main) (libc-start.c:226)
==26082==
==26082== 20 bytes in 1 blocks are still reachable in loss record 16 of 17
==26082== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082== by 0x406E9D1: xmlNewCharEncodingHandler (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x406EC02: xmlInitCharEncodingHandlers (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x41B54D2: (below main) (libc-start.c:226)
==26082==
==26082== 200 bytes in 1 blocks are still reachable in loss record 17 of 17
==26082== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==26082== by 0x406EABE: xmlInitCharEncodingHandlers (in /usr/lib/i386-linux-gnu/libxml2.so.2.7.8)
==26082== by 0x41B54D2: (below main) (libc-start.c:226)
==26082==
==26082== LEAK SUMMARY:
==26082== definitely lost: 0 bytes in 0 blocks
==26082== indirectly lost: 0 bytes in 0 blocks
==26082== possibly lost: 0 bytes in 0 blocks
==26082== still reachable: 422 bytes in 17 blocks
==26082== suppressed: 0 bytes in 0 blocks
What do? This is homework stuff - can't ignore valgrind results.
Add a call to xmlCleanupCharEncodingHandlers() right before the call to xmlCleanupParser().
On my Mac OS 10.7.5 dev machine (libxml 20703), this fixes the reported "still reachable" leaks in libxml2.
By the way, ??? means that the debugging symbols for the object file are not available. It can be very helpful when tracking down memory leaks to have this information. The procedure for installing debugging information depends on the Linux distribution. On Ubuntu, for example, you can install the libxml2 debugging information with sudo apt-get install libxml2-dbg. See https://live.gnome.org/GettingTraces/DistroSpecificInstructions
I'm using pthreads and according to valgrind I am leaking memory, like in valgrind memory leak errors when using pthread_create
The top answer says that if you pthread_join all the threads this memory will be reclaimed, but it isn't for me.
pthread_t threads[NUM_THREADS];
...
for (i = 0; i < NUM_THREADS; i++) {
pthread_create(&threads[i], &attr, Worker, NULL);
}
...
for (i = 0; i < NUM_THREADS; i++) {
pthread_join(threads[i], NULL);
}
valgrind output
==2707== HEAP SUMMARY:
==2707== in use at exit: 954 bytes in 4 blocks
==2707== total heap usage: 7,717 allocs, 7,713 frees, 79,563 bytes allocated
==2707==
==2707== 34 bytes in 1 blocks are still reachable in loss record 1 of 4
==2707== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2707== by 0x400541E: local_strdup (dl-load.c:162)
==2707== by 0x40085D3: _dl_map_object (dl-load.c:2473)
==2707== by 0x4012D5C: dl_open_worker (dl-open.c:225)
==2707== by 0x400ECBE: _dl_catch_error (dl-error.c:178)
==2707== by 0x4184D40: do_dlopen (dl-libc.c:89)
==2707== by 0x404CD4B: start_thread (pthread_create.c:308)
==2707== by 0x414BACD: clone (clone.S:130)
==2707==
==2707== 34 bytes in 1 blocks are still reachable in loss record 2 of 4
==2707== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2707== by 0x400B05A: _dl_new_object (dl-object.c:161)
==2707== by 0x4006437: _dl_map_object_from_fd (dl-load.c:1051)
==2707== by 0x400839F: _dl_map_object (dl-load.c:2568)
==2707== by 0x4012D5C: dl_open_worker (dl-open.c:225)
==2707== by 0x400ECBE: _dl_catch_error (dl-error.c:178)
==2707== by 0x4184D40: do_dlopen (dl-libc.c:89)
==2707== by 0x404CD4B: start_thread (pthread_create.c:308)
==2707== by 0x414BACD: clone (clone.S:130)
==2707==
==2707== 256 bytes in 1 blocks are still reachable in loss record 3 of 4
==2707== at 0x402A5E6: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2707== by 0x401045C: _dl_check_map_versions (dl-version.c:300)
==2707== by 0x401336A: dl_open_worker (dl-open.c:268)
==2707== by 0x400ECBE: _dl_catch_error (dl-error.c:178)
==2707== by 0x4184D40: do_dlopen (dl-libc.c:89)
==2707== by 0x404CD4B: start_thread (pthread_create.c:308)
==2707== by 0x414BACD: clone (clone.S:130)
==2707==
==2707== 630 bytes in 1 blocks are still reachable in loss record 4 of 4
==2707== at 0x402A5E6: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2707== by 0x400AE0F: _dl_new_object (dl-object.c:77)
==2707== by 0x4006437: _dl_map_object_from_fd (dl-load.c:1051)
==2707== by 0x400839F: _dl_map_object (dl-load.c:2568)
==2707== by 0x4012D5C: dl_open_worker (dl-open.c:225)
==2707== by 0x400ECBE: _dl_catch_error (dl-error.c:178)
==2707== by 0x4184D40: do_dlopen (dl-libc.c:89)
==2707== by 0x404CD4B: start_thread (pthread_create.c:308)
==2707== by 0x414BACD: clone (clone.S:130)
==2707==
==2707== LEAK SUMMARY:
==2707== definitely lost: 0 bytes in 0 blocks
==2707== indirectly lost: 0 bytes in 0 blocks
==2707== possibly lost: 0 bytes in 0 blocks
==2707== still reachable: 954 bytes in 4 blocks
==2707== suppressed: 0 bytes in 0 blocks
==2707==
==2707== For counts of detected and suppressed errors, rerun with: -v
==2707== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Am I doing something wrong or is the top answer incorrect?
This is not an actual leak and you can safely ignore it. The memory block pthread_create allocates is used for extending the thread stack and it is not freed. The library may use the same memory region for possible future calls to pthread_create.
I am probably late to the show. As pointed out, it must not have any memory leak - I checked what you have done it is standard way of creating (create internal memory for thread) and joining a thread (auto reclaims this memory).
However, you have not shown the initialization of attr.
You may try doing:
pthread_create(&threads[i], NULL, Worker, NULL);
I have placed NULL here, instead of any value for attr. The pthread initialization is tightly coupled to attribute (unless it is provided as NULL).