Sign in to follow this  

Tutorials and memory leaks

This topic is 4841 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Yesterday I finally started reading the NeHe tutorials (they are great btw), and after about 3-4 hours I have a fairly decent experiment going on (actually it's probably a pos but it seems sufficient for learning the concepts presented). However, I've found after completing it there are quite a bit of leaks. Using valgrind, the final report is: ==25705== LEAK SUMMARY: ==25705== definitely lost: 0 bytes in 0 blocks. ==25705== possibly lost: 0 bytes in 0 blocks. ==25705== still reachable: 41701 bytes in 460 blocks. ==25705== suppressed: 200 bytes in 1 blocks. which is somewhat discouraging. I feel I'm missing some sort of general openGL free call, or possibly several, but they were not covered in the tutorials. Here's the code: http://para.finop.net:81/main.c Here's the complete valgrind report: http://para.finop.net:81/log.txt Any ideas? Thanks guys :) Btw, I'm running Linux.

Share this post


Link to post
Share on other sites
Took a look at your code, and compiled it useing the Fluid Studios Mmgr code (very great stuff), and found no leaks in YOUR code. However, it does not check anything but your code. The leaks could be Glut, and one of the standard libs.

After looking through the log, all the leaks are coming from libc, libX11, libGL, etc. Nothing from your app itself. Below is the memory tracking part of MMGR.

[+] 00001 malloc of size 0x0000002C(00000044) by main.c(00298)::??
[+] ----> addr 0x003DC008
[+] 00002 malloc of size 0x0000002C(00000044) by main.c(00298)::??
[+] ----> addr 0x003DE040
[+] 00003 malloc of size 0x0000002C(00000044) by main.c(00298)::??
[+] ----> addr 0x089B1048
[-] ----- free of addr 0x003DC008 by main.c(00249)::??
[-] ----- free of addr 0x003DE040 by main.c(00249)::??
[-] ----- free of addr 0x089B1048 by main.c(00249)::??

All that you create, you destory.

Share this post


Link to post
Share on other sites
Valgrind's a fairly finicky allocation checker. It's entirely likely that a framework library such as GLUT would keep around a small and constant amount of non-freed memory, simply because there's little reason for it not to. I wouldn't worry about it. If you want, valgrind can be instructed to ignore certain unfreed memory locations; I'd add these in.

Share this post


Link to post
Share on other sites

This topic is 4841 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this