Re: Fix for 1001-local-eval-error-backtrace-segfaults - please review

[Neil Jerram]

>>>>> "thi" == Thien-Thi Nguyen <address@hidden> writes:

    thi>    From: Neil Jerram <address@hidden>
    thi>    Date: 02 May 2002 13:59:06 +0100

    thi>    The copy in scm_unmemocopy, which looks as though it might be
    thi>    intended to fix this problem [...]

    thi> was this used previously?  (i'm trying to crawl inside the head of
    thi> whoever wrote it this way in the first place.)

I don't know.  The most likely ChangeLog entry I can find is `Tue Aug
20 18:48:40 1996 Mikael Djurfeldt', which describes the initial
addition of scm_unmemocopy.

    thi>    Fix isn't very elegant, though;
    thi>    is there a nicer way of doing this?

    thi> both the old way and the new way involve mutating some nested list
    thi> structure, so i'm guessing that doesn't play into "elegance".

No; the new way doesn't mutate at all.  It creates a new environment
that shares some substructure with the old environment.

    thi> i'm wondering what is it about this fix that makes it not
    thi> very elegant?

My fix may use more consing than it needs to.  Where possible, I feel
that mutation is desirable because it's faster and doesn't encourage
the GC.  So perhaps there's a fix that still works but with fewer than
3 new pairs.

    thi>    2. Rerun of problem scenarios:

    thi> cool.  this touches upon the need to extend the testing framework to
    thi> handle interactive cases.  actually, i believe that's already possible
    thi> w/ the current framework via (ice-9 expect); the limitation really is
    thi> that all tests share an execution environment -- this is fine for the
    thi> most part, but undesirable for this kind of bug.

But, does this test need a different execution environment?  It's true
for any existing test case that, if it causes a SEGV, the following
test cases won't run.  This doesn't worry us much because SEGVs aren't
an important part of our plans :-)

        Neil