segfault in CVS HEAD

segfault in CVS HEAD

[Han-Wen Nienhuys]

(I think I've  already sent this, but I couldn't fidn a copy in my
outbox.)

this is with current CVS  head

	byrd:~/usr/src/guile/libguile$ guile --debug t.scm
	Backtrace:
	In unknown file:
	   ?: 0* [primitive-load "t.scm"]
	In t.scm:
	   1: 1* Segmentatie fout
	byrd:~/usr/src/guile/libguile$ cat t.scm
	(defiaine  blub  (cons (quote (1 . 2)) 2))


for some reason, GUILE unmemoizes the procedure during print; of
course, the expression is not memoized, since evaluation stops after
"defiaine". I've seen similar problems with invocations of
procedure-source on valid code.

Please fix - this is a serious error.


-- 

 Han-Wen Nienhuys   |   hanwen@xs4all.nl   |   http://www.xs4all.nl/~hanwen 



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

segfault in CVS HEAD

[Han-Wen Nienhuys]

hanwen@xs4all.nl writes:
> 	byrd:~/usr/src/guile/libguile$ cat t.scm
> 	(defiaine  blub  (cons (quote (1 . 2)) 2))
> 
> 
> for some reason, GUILE unmemoizes the procedure during print; of
> course, the expression is not memoized, since evaluation stops after
> "defiaine". I've seen similar problems with invocations of
> procedure-source on valid code.

example:

	byrd:~/usr/src/guile/libguile$ cat t.scm
	(define (blub)  (cons (quote (1 . 2)) 2))
	(display (procedure-source blub))
	byrd:~/usr/src/guile/libguile$ guile --debug t.scm
	Segmentatie fout
	byrd:~/usr/src/guile/libguile$ guile t.scm
	Segmentatie fout



-- 

 Han-Wen Nienhuys   |   hanwen@xs4all.nl   |   http://www.xs4all.nl/~hanwen 



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

segfault in CVS HEAD

[Han-Wen Nienhuys]

hanwen@xs4all.nl writes:
> hanwen@xs4all.nl writes:
> > 	byrd:~/usr/src/guile/libguile$ cat t.scm
> > 	(defiaine  blub  (cons (quote (1 . 2)) 2))
> > 
> > 
> > for some reason, GUILE unmemoizes the procedure during print; of
> > course, the expression is not memoized, since evaluation stops after
> > "defiaine". I've seen similar problems with invocations of
> > procedure-source on valid code.
> 
> example:
> 
> 	byrd:~/usr/src/guile/libguile$ cat t.scm
> 	(define (blub)  (cons (quote (1 . 2)) 2))
> 	(display (procedure-source blub))
> 	byrd:~/usr/src/guile/libguile$ guile --debug t.scm
> 	Segmentatie fout
> 	byrd:~/usr/src/guile/libguile$ guile t.scm
> 	Segmentatie fout

I've implemented a kludge in CVS: the for loop now has a SCM_CONSP as
the condition. It produces incorrect output in the example that I
sent, but at least it doesn't crash. 


BTW,

why are vectors quoted in the unmemoize output?  from
unmemoize_expression():


  else if (SCM_VECTORP (expr))
    {
      return scm_list_2 (scm_sym_quote, expr);
    }

-- 

 Han-Wen Nienhuys   |   hanwen@xs4all.nl   |   http://www.xs4all.nl/~hanwen 



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: segfault in CVS HEAD

[Dirk Herrmann]

Han-Wen Nienhuys wrote:

>  hanwen@xs4all.nl writes:
>
> > hanwen@xs4all.nl writes:
> >
> >> byrd:~/usr/src/guile/libguile$ cat t.scm (defiaine blub (cons
> >> (quote (1 . 2)) 2))
 >>>
> >> for some reason, GUILE unmemoizes the procedure during print; of
> >> course, the expression is not memoized, since evaluation stops
> >> after "defiaine". I've seen similar problems with invocations of
> >> procedure-source on valid code.

Sorry for answering so late. The problem is due to some changes that I 
had introduced.

>  I've implemented a kludge in CVS: the for loop now has a SCM_CONSP as
>  the condition. It produces incorrect output in the example that I
>  sent, but at least it doesn't crash.

I will fix it. Sorry again for the delay.

>  BTW,
>
>  why are vectors quoted in the unmemoize output? from
>  unmemoize_expression():

Short answer: To make the unmemoized output R5RS compliant.

Long answer, for everyone interested: According to R5RS, vector 
constants must be quoted. The reason is the following:
  #((1 + 2))
evaluates to
  #((1 + 2))
rather than
  #(3)
To make this behaviour more obvious, R5RS demands to write
  '#((1 + 2))

Guile's executor does not need to see the quotes. That is, we strip away 
the quotes during memoization since this gives a slight performance 
improvement when dealing with vector constants. When unmemoizing the 
code again, however, in order to produce syntactically correct 
unmemoized code, the required quote is added again. Please compare the 
following:

guile> (define (foo) #(1))
guile> (foo)
#(1)
guile> (procedure-source foo)
(lambda () (quote #(1)))

guile> (define (bar) '#(1))
guile> (bar)
#(1)
guile> (procedure-source bar)
(lambda () (quote #(1)))

Best regards
Dirk Herrmann




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: segfault in CVS HEAD

[Han-Wen Nienhuys]

dirk@dirk-herrmanns-seiten.de writes:
> Han-Wen Nienhuys wrote:
> 
> >  hanwen@xs4all.nl writes:
> >
> > > hanwen@xs4all.nl writes:
> > >
> > >> byrd:~/usr/src/guile/libguile$ cat t.scm (defiaine blub (cons
> > >> (quote (1 . 2)) 2))
>  >>>
> > >> for some reason, GUILE unmemoizes the procedure during print; of
> > >> course, the expression is not memoized, since evaluation stops
> > >> after "defiaine". I've seen similar problems with invocations of
> > >> procedure-source on valid code.
> 
> Sorry for answering so late. The problem is due to some changes that I 
> had introduced.

DO you have any idea when these issues will be fixed in CVS HEAD? 

Thanks,

Han-Wen

-- 

 Han-Wen Nienhuys   |   hanwen@xs4all.nl   |   http://www.xs4all.nl/~hanwen 



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: segfault in CVS HEAD

[Dirk Herrmann]

Han-Wen Nienhuys wrote:

>DO you have any idea when these issues will be fixed in CVS HEAD? 
>
Hopefully they are fixed now.

Best regards,
Dirk



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: segfault in CVS HEAD

[Jan Nieuwenhuizen]

Dirk Herrmann writes:

> Hopefully they are fixed now.

Yes, they are for me (ie, for guile-gnome).

Thanks!
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: segfault in CVS HEAD

[Han-Wen Nienhuys]

hanwen@xs4all.nl writes:
> > had introduced.
> 
> DO you have any idea when these issues will be fixed in CVS HEAD? 
> 

unfortunately, your fix was not completely successful:



In unknown file:
   ?:  0* [lilypond-main ("input/regression/lily-in-scheme")]
In /home/hanwen/usr/src/lilypond/scm/lily.scm:
 556:  1* 
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1074533568 (LWP 27330)]
unmemoize_expression (expr=0x21c, env=0x404) at eval.c:549
(gdb) l
544	
545	      for (frame_idx = env, frame_nr = SCM_IFRAME (expr);
546	           frame_nr != 0; 
547	           frame_idx = SCM_CDR (frame_idx), --frame_nr)
548	        ;
549	      for (symbol_idx = SCM_CAAR (frame_idx), symbol_nr = SCM_IDIST (expr);
550	           symbol_nr != 0;
551	           symbol_idx = SCM_CDR (symbol_idx), --symbol_nr)
552	        ;
553	      return SCM_ICDRP (expr) ? symbol_idx : SCM_CAR (symbol_idx);
(gdb) ps expr
#@2+0
$25 = void
(gdb) ps env
()
$26 = void
(gdb) up
#1  0x4002c2f8 in unmemoize_exprs (exprs=0x404de0b8, env=0x404fdba0)
    at eval.c:597
(gdb) ps exprs
(#<variable 403c85b0 value: #<primitive-generic for-each>> (#@lambda (f) (#<variable 402d0c98 value: #<primitive-procedure catch>> (#@quote . ly-file-failed) (#@lambda () (#<variable 402ee878 value: #<primitive-procedure ly:parse-file>> #@1+0)) #@1-0)) #@2+0)
$27 = void
(gdb) ps env
(((files) (input/regression/lily-in-scheme)) #<eval-closure 403067f8>)
$28 = void
(gdb)



-- 

 Han-Wen Nienhuys   |   hanwen@xs4all.nl   |   http://www.xs4all.nl/~hanwen 



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: segfault in CVS HEAD

[Dirk Herrmann]

Han-Wen Nienhuys wrote:

>unfortunately, your fix was not completely successful:
>
Sorry, but I don't have sufficient information yet. Could you provide a 
simple test case that allows to reproduce the problem? If that is not 
possible, I could probably also do with a stack backtrace together with 
the printout of the expression and environment at the uppermost call to 
an unmemoization function.

Sorry for the inconvenience,
Dirk



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: segfault in CVS HEAD

[Han-Wen Nienhuys]

dirk@dirk-herrmanns-seiten.de writes:
> Han-Wen Nienhuys wrote:
> 
> >unfortunately, your fix was not completely successful:
> >
> Sorry, but I don't have sufficient information yet. Could you provide a 
> simple test case that allows to reproduce the problem? If that is not 
> possible, I could probably also do with a stack backtrace together with 
> the printout of the expression and environment at the uppermost call to 
> an unmemoization function.
> 
> Sorry for the inconvenience,
> Dirk

I don't have time now to isolate a failure case. The best I can do is:
get lilypond-2.3.5 (go to lilypond.org), compile it, remove comments
(the %{  and %} ) from

    input/regression/lily-in-scheme.ly

and do

   lily/out/lilypond-bin -V input/regression/lily-in-scheme.ly

this will produce a similar crash. 


(gdb) down
#3  0x4002ecd4 in scm_unmemocopy (forms=0x404ded30, env=0x404fe798)
    at eval.c:2401
2401      const SCM um_forms = unmemoize_exprs (forms, env);
(gdb) ps forms
(#@let* (failed (#@quote) handler (#@lambda (key arg) #@lambda (set! failed (cons arg failed)))) (#<variable 403c7ba8 value: #<primitive-generic for-each>> (#@lambda (f) (#<variable 402d0c98 value: #<primitive-procedure catch>> (#@quote . ly-file-failed) (#@lambda () (#<variable 402ee878 value: #<primitive-procedure ly:parse-file>> #@1+0)) #@1-0)) #@2+0) (if (pair? failed) (begin (display (string-append 
 *** Failed files:  (string-join failed) 
)) (exit 1)) (exit 0)))
$3 = void
(gdb) ps env
(((files) (input/regression/lily-in-scheme.ly)) #<eval-closure 403067f8>)
$4 = void
(gdb) bt
#0  unmemoize_expression (expr=0x21c, env=0x404) at eval.c:549
#1  0x4002c2f8 in unmemoize_exprs (exprs=0x404deb88, env=0x404fe798)
    at eval.c:597
#2  0x4002c2f8 in unmemoize_exprs (exprs=0x404ded30, env=0x404fe798)
    at eval.c:597
#3  0x4002ecd4 in scm_unmemocopy (forms=0x404ded30, env=0x404fe798)
    at eval.c:2401
#4  0x40025174 in scm_unmemoize (m=0x21c) at debug.c:282
#5  0x40021d23 in display_frame (frame=0x405fd220, nfield=2, indentation=1, 
    sport=0x405fd2c0, port=0x402d41d8, pstate=0x82b1680) at backtrace.c:621
#6  0x40022023 in display_backtrace_body (a=0xbfffd860) at backtrace.c:728
#7  0x4006ec5d in scm_internal_catch (tag=0x104, 
    body=0x40021dc4 <display_backtrace_body>, body_data=0xbfffd860, 
    handler=0x40021324 <display_error_handler>, handler_data=0xbfffd858)
    at throw.c:172
#8  0x4002220b in scm_display_backtrace (stack=0x0, port=0x404, first=0x0, 
    depth=0x0) at backtrace.c:758
#9  0x4006f11e in handler_message (handler_data=0x0, tag=0x824c8a0, 
    args=0x405fd360) at throw.c:401
#10 0x4006f1a0 in scm_handle_by_message (handler_data=0x0, tag=0x824c8a0, 
    args=0x405fd360) at throw.c:452
#11 0x4006f3fc in scm_ithrow (key=0x824c8a0, args=0x405fd360, noreturn=1)
    at throw.c:597
#12 0x4002afc1 in scm_error (key=0x824c8a0, subr=0x0, 
    message=0x404 <Address 0x404 out of bounds>, args=0x405fd388, rest=0x4)
    at error.c:71

> 

-- 

 Han-Wen Nienhuys   |   hanwen@xs4all.nl   |   http://www.xs4all.nl/~hanwen 



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: segfault in CVS HEAD

[Dirk Herrmann]

Bill Schottstaedt wrote:

> There's still one case where the lambda tag appears --
> if you include a documentation string:
>
> guile> (define (hi) "this is a comment" 34)
> guile> (procedure-source hi)
> (lambda () "this is a comment" #@lambda 34)
>
> Also I notice that "let" is sometimes changed to "let*", and
> in the define* case I get "(lambda lambda*:G0 (let-optional* 
> lambda*:G0" etc. 

I will take care of the problem in about two or three weeks. (Got just 
married last week, will leave for honeymoon in about one hour...)

Best regards,
Dirk



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: segfault in CVS HEAD

[Dale P. Smith]

Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:

> I will take care of the problem in about two or three weeks. (Got just
> married last week, will leave for honeymoon in about one hour...)

Wow!  Congratulations Dirk.  May God richly bless your life together.

-Dale
-- 
Dale P. Smith
dsmith at actron dot com


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: segfault in CVS HEAD

[Dirk Herrmann]

Bill Schottstaedt wrote:

> There's still one case where the lambda tag appears --
> if you include a documentation string:
>
> guile> (define (hi) "this is a comment" 34)
> guile> (procedure-source hi)
> (lambda () "this is a comment" #@lambda 34)
>
> Also I notice that "let" is sometimes changed to "let*", and
> in the define* case I get "(lambda lambda*:G0 (let-optional* 
> lambda*:G0" etc. 

Sorry for the delay. I have submitted a patch, that fixes the 
documentation string issue.

Regarding let being changed to let*: As far as I know, guile has always 
done such conversions in certain circumstances, not just since my recent 
changes. In the medium term, there will probably even more of such 
conversions be introduced, since they are intended as optimizations. Do 
the recent changes introduce a problem for you, or was this just to be 
seen as a general comment? If it is a problem for you, could you please 
give more details and also some examples?

Thanks a lot, and sorry again for the delay until I fixed the code.
Best regards,
Dirk



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: segfault in CVS HEAD

[Bill Schottstaedt]

 > Sorry for the delay. I have submitted a patch, that fixes the documentation string issue.

Thanks -- my test suite is happy again!


 > Regarding let being changed to let*: As far as I know, guile has always done
 > such conversions in certain circumstances, not just since my recent changes.

I noticed more such changes recently -- they aren't incorrect, just annoying
if you're writing auto-testing stuff, and need to check that procedures are
correctly set up.  They're not a big problem.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel