Hi, I'm facing a strange issue. My program normally runs quite well. Just once upon a time (that is sometimes only after hours plus a sleep mode, however under certain circumstances upon ~70% of starts within the first few seconds) it will start to eat memory as if it where electricity.
Tracking that down seems hard. There is no unexpected heap usage according to ##sys#dump-heap-state and ##sys#memory-info. Furthermore there is no indication so far that elsewhere a memory leak would exist. (I added tracking code to those few malloc/free pairs I have.) Time to learn how to use valgrind. ... I thought, so at worst this is a "help me learning" request of mine. To begin with I rebuild my chicken with DEBUGBUILD=1 (and my app too). The expected slow down is in fact worse enough to trigger my "app alive" watchdog. But for half a minute it runs quite well. Except that valgrind will report problems: ==14864== Conditional jump or move depends on uninitialised value(s) ==14864== at 0x531AB24: C_equalp (runtime.c:3909) ==14864== by 0x4F5F816: f_6610 (library.c:38125) ==14864== by 0x519853B: f_19858 (irregex.c:12514) ==14864== by 0x5198B2C: f_19929 (irregex.c:12591) ==14864== by 0x51988B0: f_19843 (irregex.c:12562) ==14864== by 0x4F47532: f_9742 (library.c:32791) Note that line numbers in runtime.c will be off - I added some debug code there. So untime.c:3909 resolves to C_equalp right after the "loop:" label: loop: if(x == y) return 1; Around 30 lines down we find: x = C_block_item(x, i); y = C_block_item(y, i); goto loop; which I take as looking suspicious. The i just ran from 0 while i < (n = header & C_HEADER_SIZE_MASK). Now I might missread the source, but at that point I'd assume that C_block_item(x-or-y, i) would be off-by-one. But wait! I tried to change the procedure and instead of those 3 lines I left a "return 1;" there. This seems at least to work well for some simple checks in csi. But my app will now: a) run without valgrinds complaint b) into an endless loop. Taking into account that while compiling the DEBUGBUILD I ignored a ton of warnings about type issues in irregex.scm, I'm kinda alarmed that those calls to the questionable equal? originated from irregex. So the first question would be: why do we "goto loop;" here? If this is correct, it looks weird enough IMHO to warrent a comment in the source code. If those three lines could be replaced by return 1; then they should be for clarity. In the latter case however we would probably have a problem in irregex. don't we? /Jörg ....... _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users