Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

heap leak when test string_utilities.c #10

Open
siriusdemon opened this issue Jan 5, 2018 · 1 comment
Open

heap leak when test string_utilities.c #10

siriusdemon opened this issue Jan 5, 2018 · 1 comment

Comments

@siriusdemon
Copy link

Hi
I met a problem when test string_utilities.c, I ran valgrind and found heap leak. But I was unable to locate and solve the problem.


system info

OS: Ubuntu Mate 17.10
Linux version 4.13.0-21-generic
gcc version 7.2.0
valgrind: 3-13.0


reproduce

compile with
gcc string_utilities.c -g -Wall -std=gnu11 -Dtest_ok_array `pkg-config --cflags glib-2.0` `pkg-config --libs glib-2.0` -o string_utilities


run with
valgrind ./string_utilities

report:
==1096== Memcheck, a memory error detector
==1096== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1096== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==1096== Command: ./string_utilities
==1096==
OK.
==1096==
==1096== HEAP SUMMARY:
==1096== in use at exit: 18,604 bytes in 6 blocks
==1096== total heap usage: 14 allocs, 8 frees, 19,802 bytes allocated
==1096==
==1096== LEAK SUMMARY:
==1096== definitely lost: 0 bytes in 0 blocks
==1096== indirectly lost: 0 bytes in 0 blocks
==1096== possibly lost: 0 bytes in 0 blocks
==1096== still reachable: 18,604 bytes in 6 blocks
==1096== suppressed: 0 bytes in 0 blocks
==1096== Rerun with --leak-check=full to see details of leaked memory
==1096==
==1096== For counts of detected and suppressed errors, rerun with: -v
==1096== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

@b-k
Copy link
Owner

b-k commented Jun 18, 2018

Try using
valgrind --leak-check=yes ./charct

A lot of things don't get explicitly closed out at the end of the sample programs, because one of the themes of the book is that we don't have to supervise every byte, and the system closes file handles and frees memory on exit for us. But if you'd like to investigate using the above and submit a pull request explicitly closing out the dropped items, I'd be happy to accept it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants