Jörg F. Wittenberger
2011-09-24 16:08:13 UTC
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
So untime.c:3909 resolves to C_equalp right after the "loop:" label:
if(x == y) return 1;
Around 30 lines down we find:
x = C_block_item(x, i);
y = C_block_item(y, i);
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.
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
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
then they should be for clarity.
In the latter case however we would probably have a problem in irregex.