[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jörg F . Wittenberger
Subject: Re: [Chicken-users] a memory issue; mildly scaring to me
Date: 26 Sep 2011 17:04:12 +0200

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]