[Chicken-users] a memory issue; mildly scaring to me

[Jörg F . Wittenberger]

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
.......