[Top][All Lists]

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

Re: [Chicken-hackers] [PATCH] Add aggressive debugging checks to squash

From: Christian Kellermann
Subject: Re: [Chicken-hackers] [PATCH] Add aggressive debugging checks to squash those damn bugs
Date: Wed, 2 Oct 2013 14:44:44 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

* Peter Bex <address@hidden> [130930 23:51]:
> On Sun, Sep 29, 2013 at 10:46:25PM +0200, Peter Bex wrote:
> > The first patch adds assertions to all the type accessors like C_unfix,
> > C_block_{header,item}, C_character_code etc.  It does this through a
> > "check" macro which contains a horrible, evil hack which allows LET-like
> > semantics in C macros, in a bit of a manual way.
> > If you'd like more info, let me know and I'll try to clarify.  Also, if
> > anyone knows of a way to do this in a less verbose, ugly way, please let
> > me know!
> > 
> > The patch also cleans up a few unused macros and ensures all macros
> > nicely use the C_(set)_block_item, C_block_header and C_data_pointer to
> > access the C_SCHEME_BLOCK objects.  This cleans up things a bit (and in
> > this case, ensures the assertions are triggered when things are wrong).
> I ran into a slight setback with this patch: the fx... procedures are all
> unsafe and marked as clean (ie, non-mutating), which is correct.
> Unfortunately, this means that the optimizer will attempt to
> constant-fold them, even in situations like irregex's flag-join.
> You see this happen when you compile a new DEBUGBUILD CHICKEN with
> itself; it'll crash when compiling irregex.scm.
> Here's a simple test program that reproduces the slightly more complex
> situation in irregex-core:
> (define (flag-join a b)
>   (if b (fxior a b) a))
> (print (flag-join 1 #f))
> This will crash the compiler with a panic due to an assertion failure:
> the constant-folder is invoking (fxior 1 #f) because they're all
> constants.  Normally, such a bogus thing will raise an exception and
> the constant folder will stop, but these procedures are unsafe and
> unchecked.  This won't cause an issue in practice because the
> constant-folded expression is never reached and may even be eliminated
> in a later optimisation step, but the damage is done already.
> So to avoid these issues I've decided to apply the checks less strictly
> and only on the actual unboxing operations that shouldn't be accessed
> straight from Scheme anyway (but it may get hit anyway if I'm
> overlooking anything).  Unfortunately, there's still one use of CHECK2
> left in the code, and it's the most important one so I had to keep it.
> I've also removed the trailing whitespace in patch 0003, which was
> already there in library.scm, but git complains when applying it.
> So here are all 4 patches again, with 1 and 3 different from last time.

Thanks Peter, I have pushed all of them, let's see what a salmonella
run does to it. It cannot get worse...

Kind regards,


In the world, there is nothing more submissive and weak than
water. Yet for attacking that which is hard and strong, nothing can
surpass it. --- Lao Tzu

reply via email to

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