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

[Jörg F . Wittenberger]

On Sep 26 2011, Peter Bex wrote:

> On Mon, Sep 26, 2011 at 03:16:07PM +0200, Jörg F. Wittenberger wrote:
> > >While it does not fix the problem at hand:
> > >
> > >There is a suspicious line in regex-core.scm 2222:
> > >
> > >it reads:
> > >
> > >   (printing or graphic whitespace)
> > >
> > >IMHO it should read:
> > >
> > >   (printing . (or graphic whitespace))
> >
> > BTW: I know that those are the same.  It's just confusing the reader,
> > when the same list is written both styles.
>
> Maybe. This can be fixed, but it's not the issue here.
>
> > Ah: since parameter checking might be off in the chicken core (is it?),
> > what would happen, if we use a parameter, which has not been passed?
> > Might that be the uninitialized value from a stack allocation, which
> > I see from valgrind?
> >
> > What should be done?
>
> Why don't you try your regex code with upstream irregex itself?

This looks infeasible expensive to me.  A ton of them scattered all around
in many source files.  Some are for historical reasons dispatched to pcre.
I will not be able to say which one are checked and passed good.

Furthermore recall: the issue will only appear sometimes. Or might be 
hinted to from valgrind output.

Alls those hints however point into irregex toplevel initialisation.
There seems to be a good chance that they will pass all in the interpreter.

At the other hand there is no evidence that a *particular* regex is the
cause.  So far I have two complaints from valgrind with the same sequence
of calls and one different.  Both the C functions appear to do toplevel
initializations.  Only one of them is about sre-named-definitions.

Hence I'm afraid that my considerations wrt. possible irregex weirdness
might be both correct and irrelevant at the same time.  At worst.

I fail to see a test plan on that path.

> Just (load "irregex.scm") and then run your regex match.
> Then it will run with all checks enabled, at slow speed, but at least
> it'll fail when something is broken.
>
> All this speculation is kind of pointless without a proper testcase.

That's the problem in fact.

So far I'm trying pin one down.

I'll try instead to make a version of libchicken with the checks enforced.