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

[Jörg F . Wittenberger]

On Sep 24 2011, Peter Bex wrote:

> Please try the current master first; it contains some bugfixes to
> the types database, which make those irregex errors go away
> (changeset 0fbbba9d5fc0dcce7b2364beaf3396d501967d0e).

So I did (I hope).

Remaining "Note:"-labeld warnings in irregex.scm which look as if they
could be relevant:


Note: in local procedure `lp',
 in local procedure `collect/terms',
 in local procedure `lp',
 in toplevel procedure `string->sre':
 irregex-core.scm:806: in procedure call to `pair?', the predicate is 
called with an argument of type
 `pair' and will always return true

Note: in local procedure `lp',
 in local procedure `collect/terms',
 in local procedure `lp',
 in toplevel procedure `string->sre':
 irregex-core.scm:811: in procedure call to `pair?', the predicate is 
called with an argument of type
 `(pair (pair * pair) *)' and will always return true

All remarks like
Note: global variable `XXX' is only locally visible and never used
removed.

Valgrinds complains look similar as before, but are off now:

==9367== Conditional jump or move depends on uninitialised value(s)
==9367==    at 0x531DA93: C_equalp (runtime.c:3902)
==9367==    by 0x4F600D3: f_6609 (library.c:38818)
==9367==    by 0x519B067: f_20818 (irregex.c:12516)
==9367==    by 0x519B649: f_20889 (irregex.c:12593)
==9367==    by 0x519B3CD: f_20803 (irregex.c:12564)
==9367==    by 0x4F47C7B: f_9740 (library.c:33397)
==9367==    by 0x5365F32: allocate_vector_2 (runtime.c:7089)
==9367==    by 0x5365B99: C_allocate_vector (runtime.c:7039)
==9367==    by 0x4F4816D: f_9702 (library.c:33468)
==9367==    by 0x4F480E1: f_9695r (library.c:33455)
==9367==    by 0x4F47FBE: f_9695 (library.c:33439)
==9367==    by 0x4F47B28: f_9724 (library.c:33381)
==9367==  Uninitialised value was created by a stack allocation
==9367==    at 0x5178540: f_7287 (irregex.c:6181)

Whereby

runtime.c:3902 is - as before - right after the "loop:" label.

There are so far 3 occurences within the time period my prog runs
under valgrind (which would be something like 2 seconds wall clock
until killed for being 50 times too slow or something).

Two have the same source:

==9367==  Uninitialised value was created by a stack allocation
==9367==    at 0x5178540: f_7287 (irregex.c:6181)

while the third has

==9367==  Uninitialised value was created by a stack allocation
==9367==    at 0x517A5F8: f_17819 (irregex.c:6370)

Hm.  From the surrounding hints in the C file I can roughly trace those
lines back right into the middle of irregex-corw.scm - whatever that's
worth.

so far the problem remains the same.