Advertisement

Tutorials and memory leaks

Started by September 14, 2004 02:11 PM
1 comment, last by Sneftel 20 years, 2 months ago
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.
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.
Advertisement
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.

This topic is closed to new replies.

Advertisement