headers
Neil Jerram | 2 May 2002 14:59

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

Patch

--- /home/neil/Guile/1.6/guile-core/libguile/eval.c.old	Thu May  2 12:45:56 2002
+++ /home/neil/Guile/1.6/guile-core/libguile/eval.c	Thu May  2 12:46:21 2002
 <at>  <at>  -1417,7 +1417,9  <at>  <at> 
 	ls = scm_cons (scm_sym_define,
 		       z = scm_cons (n = SCM_CAR (x), SCM_UNSPECIFIED));
 	if (SCM_NNULLP (env))
-	  SCM_SETCAR (SCM_CAR (env), scm_cons (n, SCM_CAR (SCM_CAR (env))));
+	  env = scm_cons (scm_cons (scm_cons (n, SCM_CAAR (env)),
+				    SCM_CDAR (env)),
+			  SCM_CDR (env));
 	break;
       }
     case SCM_BIT8(SCM_MAKISYM (0)):

Diagnosis

If scm_unmemocopy is called (e.g. from scm_backtrace) to unmemoize an
expression that has an internal define (i.e. SCM_IM_DEFINE) near the
top level of the expression, the code in unmemocopy can modify the
expression passed in.  The modification is such that an extra copy of
the symbol being defined is added on every call, thus:

  (((args) 4) ...)
  (((xxx args) 4) ...)
  (((xxx xxx args) 4) ...)

and so on, and this modification eventually causes some other code
that looks at the environment to SEGV.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Thien-Thi Nguyen | 3 May 2002 05:50

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

   From: Neil Jerram <neil <at> ossau.uklinux.net>
   Date: 02 May 2002 13:59:06 +0100

   -	  SCM_SETCAR (SCM_CAR (env), scm_cons (n, SCM_CAR (SCM_CAR (env))));

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

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

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

both the old way and the new way involve mutating some nested list
structure, so i'm guessing that doesn't play into "elegance".  i'm
wondering what is it about this fix that makes it not very elegant?

   2. Rerun of problem scenarios:

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

thi

_______________________________________________
Bug-guile mailing list
(Continue reading)

Permalink | Reply | 3 comments |
headers
Thien-Thi Nguyen | 4 May 2002 01:01

install-data-local scheduling not guaranteed

in branch_release-1-6 ice-9/Makefile.am, we use `install-data-local' to
install "and-let*.scm".  w/ automake 1.5 (no idea what was before), this
frag is run before the rest of the install, and fails if there is no
destination directory already set up.  the failure is masked by the "-"
action prefix, which is fine (considering the reason for using this
mechanism in the first place -- slackful handling of sites where "*" is
not a valid file name).

automake documentation sez:

> Extending installation
> ======================
> 
>    It is possible to extend this mechanism by defining an
> `install-exec-local' or `install-data-local' target.  If these targets
> exist, they will be run at `make install' time.  These rules can do
> almost anything; care is required.
> 
>    Automake also supports two install hooks, `install-exec-hook' and
> `install-data-hook'.  These hooks are run after all other install rules
> of the appropriate type, exec or data, have completed.  So, for
> instance, it is possible to perform post-installation modifications
> using an install hook.

so probably we should use `install-data-hook' instead.  i'll test this
and commit changes shortly, presuming all goes well.

thi

_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Davide Angelocola | 3 May 2002 13:18
Picon

Compilation fix for guile 1.4

(Hi),
  I've downloaded guile version 1.4 to learn on how to program
in C under UNIX. However, when I try to compile it on my
RedHat 7.2 machine I get an error in net_db.c line 85. Well, I've 
just put a comment at the beginning of line and all works fine 
now.

Now I'm learning some guile basis but I wish a more 
user-friendly interpreter:
	o  add readline and history support
	o  add a welcome message like this:
		guile v. 	[build info?]
		Copyright 
		
		Type (help) for more information

	o  add "(copyright)", "(license)" functions
	o  the "(help)" output in one page
	o  add a TODO file in the source dist
		(this can very useful for me)

I hope that this email can be useful for you! 

Bye 
Davide Angelocola

_______________________________________________
Bug-guile mailing list
Bug-guile <at> gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thien-Thi Nguyen | 4 May 2002 22:18

Re: Compilation fix for guile 1.4

   From: Davide Angelocola <davide178 <at> inwind.it>
   Date: Fri, 3 May 2002 13:18:23 +0200

     I've downloaded guile version 1.4 to learn on how to program
   in C under UNIX. However, when I try to compile it on my
   RedHat 7.2 machine I get an error in net_db.c line 85. Well, I've 
   just put a comment at the beginning of line and all works fine 
   now.

thanks for trying out guile.  the problem you report will be fixed in
1.4.1 and later versions.

	   o  add readline and history support

this is already available, but the documentation doesn't tell you how to
enable it (it's a documentation bug).  for now, see NEWS for more info.

	   o  add a welcome message like this:
		   guile v. 	[build info?]
		   Copyright 

		   Type (help) for more information

	   o  add "(copyright)", "(license)" functions
	   o  the "(help)" output in one page
	   o  add a TODO file in the source dist
		   (this can very useful for me)

   I hope that this email can be useful for you!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neil Jerram | 5 May 2002 16:00

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

>>>>> "thi" == Thien-Thi Nguyen <ttn <at> giblet.glug.org> writes:

    thi>    From: Neil Jerram <neil <at> ossau.uklinux.net>
    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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Neil Jerram | 7 May 2002 21:30

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

>>>>> "Marius" == Marius Vollmer <mvo <at> zagadka.ping.de> writes:

    Marius> Neil Jerram <neil <at> ossau.uklinux.net> writes:
    >> Basically, avoid modifying the environment in hand by making new list
    >> structure instead.  This is similar to almost all the other cases in
    >> unmemocopy, which use EXTEND_ENV.

    Marius> Great!  (In case you are waiting for a go ahead: Go Ahead! :)

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

    Marius> I don't think we should worry too much about elegance in this part of
    Marius> the code.

OK.  Any thoughts on whether this is worth putting into the stable
branch as well?  I assume it's Rob's decision...

        Neil

_______________________________________________
Bug-guile mailing list
Bug-guile <at> gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
Permalink | Reply | 2 comments |
headers
Marius Vollmer | 7 May 2002 21:39
Picon
Picon

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

Neil Jerram <neil <at> ossau.uklinux.net> writes:

> OK.  Any thoughts on whether this is worth putting into the stable
> branch as well?  I assume it's Rob's decision...

If I understand the issue right (which I probably don't), the lossage
only occurs together with 'local-eval', right?

If that is the case, my opinion would be that it is not worth fixing
it in 'stable' and risking new obscure bugs.

_______________________________________________
Bug-guile mailing list
Bug-guile <at> gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
Permalink | Reply | 1 comment |
headers
Marius Vollmer | 7 May 2002 20:36
Picon
Picon

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

Neil Jerram <neil <at> ossau.uklinux.net> writes:

> Basically, avoid modifying the environment in hand by making new list
> structure instead.  This is similar to almost all the other cases in
> unmemocopy, which use EXTEND_ENV.

Great!  (In case you are waiting for a go ahead: Go Ahead! :)

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

I don't think we should worry too much about elegance in this part of
the code.

_______________________________________________
Bug-guile mailing list
Bug-guile <at> gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
Permalink | Reply | 3 comments |
headers
Marius Vollmer | 7 May 2002 20:19
Picon
Picon

Re: GOOPS bug found?

Andreas Rottmann <a.rottmann <at> gmx.at> writes:

> As my C++ <-> Guile bindings (ucxx.sf.net) are approaching
> completeness, I have run into another strange problem. I have managed
> to isolate the code that causes it and wrote a self-contained C
> program that exposes the bug. 

Thanks!  I have recorded this as bug 'goops-1'.  I haven't looked at
it yet.  If you can investigate this further, that would be great...
please refer to bug 'goops-1' if you have some followup.

_______________________________________________
Bug-guile mailing list
Bug-guile <at> gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
Permalink | Reply | 3 comments |

Gmane