|
From: Stephen L. <sl...@al...> - 2007-12-08 00:38:17
|
Thanks for the advice. Your quick response and time are greatly appreciated. I really should have disciovered Valgrind before i wrote my 9,000 lines of C code. :-) If you don't mind, I have a few more concerns - just part of the learning curve I guess. I inserted the line --max -stackframe=2524636 and was able to see some other more specific problems with the code. One being some variables being used before they were initialized. That was easily fixed. I then added on the --show-reachable=yes to track down some malloc issues (see below). I agree that too much on the stack is a problem. I have inadvertantly built some "monster functions" so I will try to break them down into smaller parts. However, I do have a few newbie questions: QUESTION: Is the best way to manage the stack usage to break the processing task into more steps and intermediate functions, or is the stack better controlled through the complexity of some of the customized structures I am using? For example, in my example, the some of the structures have multiple fields of doubles with sizes like double[720][32], double[720][5], double[720][5], long int[720]. I guess you culd get to the 2,524,636 byte limit pretty quickly! QUESTION: When you pass a pointer to a structure that has more than 2,524,636 bytes, is that the same as saying your are going to throw that must on the stack? QUESTION: In other words, is the --max -stackframe=2524636 in the Valgrind comamnd just masking the problem which I should be fixing anyway? If that's the case, I may have to re-design a few things but perhaps it will be worth it. Also, although I am running this program on a Linux x86 box, it will actually be used on a NASA experiment which uses the Arcturus embedded uClinux system - which doesn't even have a floating point processor (Ugh!). In addition, we have been advised to avoid "malloc" like the plague as this system does not handle that relably. That's not a problem - all of our arrays are of fixed and/or known max sizes. Nonetheless, when I ran Valgrind just now, i got the following message regarding malloc: --30108-- REDIR: 0x40C7FA0 (rindex) redirected to 0x40221C0 (rindex) --30108-- REDIR: 0x40C7BF0 (strlen) redirected to 0x4022480 (strlen) --30108-- REDIR: 0x40C3590 (malloc) redirected to 0x402159B (malloc) --30108-- REDIR: 0x40C9330 (memcpy) redirected to 0x4022E50 (memcpy) --30108-- REDIR: 0x40C8940 (memchr) redirected to 0x4022670 (memchr) --30108-- REDIR: 0x40C9BE0 (rawmemchr) redirected to 0x4022850 (rawmemchr) --30108-- REDIR: 0x40C4DA0 (free) redirected to 0x40211B5 (free) QUESTION: What does the REDIR: message mean? I am also assuming that malloc is being indirectly. QUESTION: How can the following summary help find out which functions are being called - and can their memory be "free'd?". --30125-- REDIR: 0x40C8E40 (memset) redirected to 0x4022790 (memset) ==30125== ==30125== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 1) --30125-- --30125-- supp: 13 dl-hack3 ==30125== malloc/free: in use at exit: 2,464 bytes in 7 blocks. ==30125== malloc/free: 12 allocs, 5 frees, 4,224 bytes allocated. ==30125== ==30125== searching for pointers to 7 not-freed blocks. ==30125== checked 72,588 bytes. ==30125== ==30125== 2,464 bytes in 7 blocks are still reachable in loss record 1 of 1 ==30125== at 0x4021620: malloc (vg_replace_malloc.c:149) ==30125== ==30125== LEAK SUMMARY: ==30125== definitely lost: 0 bytes in 0 blocks. ==30125== possibly lost: 0 bytes in 0 blocks. ==30125== still reachable: 2,464 bytes in 7 blocks. ==30125== suppressed: 0 bytes in 0 blocks. --30125-- memcheck: sanity checks: 1545 cheap, 62 expensive --30125-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --30125-- memcheck: auxmaps: 0 searches, 0 comparisons --30125-- memcheck: SMs: n_issued = 65 (1040k, 1M) --30125-- memcheck: SMs: n_deissued = 53 (848k, 0M) --30125-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M) --30125-- memcheck: SMs: max_undefined = 40 (640k, 0M) --30125-- memcheck: SMs: max_defined = 21 (336k, 0M) --30125-- memcheck: SMs: max_non_DSM = 23 (368k, 0M) --30125-- memcheck: max sec V bit nodes: 0 (0k, 0M) --30125-- memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0) --30125-- memcheck: max shadow mem size: 672k, 0M --30125-- translate: fast SP updates identified: 3,210 ( 88.6%) --30125-- translate: generic_known SP updates identified: 222 ( 6.1%) --30125-- translate: generic_unknown SP updates identified: 187 ( 5.1%) --30125-- tt/tc: 492,431 tt lookups requiring 492,708 probes --30125-- tt/tc: 492,431 fast-cache updates, 2 flushes --30125-- transtab: new 4,347 (125,377 -> 2,013,007; ratio 160:10) [0 scs] --30125-- transtab: dumped 0 (0 -> ??) --30125-- transtab: discarded 0 (0 -> ??) --30125-- scheduler: 154,584,422 jumps (bb entries). --30125-- scheduler: 1,545/492,953 major/minor sched events. --30125-- sanity: 1546 cheap, 62 expensive checks. --30125-- exectx: 30,011 lists, 8 contexts (avg 0 per list) --30125-- exectx: 30 searches, 22 full compares (733 per 1000) --30125-- exectx: 6 cmp2, 30 cmp4, 0 cmpAll Thanks for your valuable time and expertise! Steve Licata |