bug-guile
[Top][All Lists]
Advanced

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

segvs on memoized macro backtraces


From: Kevin Ryde
Subject: segvs on memoized macro backtraces
Date: Tue, 18 Feb 2003 07:55:45 +1000
User-agent: Gnus/5.090013 (Oort Gnus v0.13) Emacs/21.2 (i386-pc-linux-gnu)

In guile 1.6.3 built on a recent i386 debian, I struck a couple of
cases where memoized macros seem to induce segmentation violations
during a backtrace print.

The files foo.scm and bar.scm are two examples, each independent, to
be run as

        guile --debug -s foo.scm
        guile --debug -s bar.scm

Each results in a partial backtrace printout then a segmentation
violation, whereas naturally I hoped for a full printout.


foo.scm has an obviously incorrect "let", as revealled by running
without --debug.  Still, it'd be nice to get a backtrace to locate the
problem.

For what it's worth, gdb suggests perhaps unmemocopy has gone into an
infinite or very long recursion (the call under the "loop" label),
apparently overflowing the stack (the faulting insn being a pushl).


bar.scm produces a correct macro expansion, I believe.  (Uncommenting
the pretty-print in the file shows what's being executed, or is
supposed to be executed.)  But the record-accessor call is requesting
an incorrect field.  Running without --debug shows that error.

For what it's worth, gdb suggests scm_unmemocar has been reached with
an "env" list of just one element, whereas SCM_IFRAME is 1, for which
an env of two or more elements is apparently expected.  (But all this
is a mystery to me, so I wouldn't necessarily trust that analysis).


Attachment: foo.scm
Description: Binary data

Attachment: bar.scm
Description: Binary data


reply via email to

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