[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Problem with XScheme 0.16
I have been using XScheme 0.16 for about 6 months, now, and find it
to be quite useful. I have been running it on Silicon Graphics
workstations, specifically, the IRIS 3130 and the Personal Iris.
In all the time I have been using the program, I have found only
one non-trivial bug. The author of XScheme, David Betz, deserves
considerable praise for the robustness and performance of XScheme.
Having been inside the source, I have found it to be some of the
cleanest, easiest-to-understand C code I have ever seen. However,
I have determined that I will be unable to debug the problem
without spending several days instrumenting the code. I have
written to David to ask his help, and I thought I might query the
network, too, in case someone out there has already solved the
problem and can save me those few days' work.
The following operations cause a "segmentation violation" on the
Personal Iris
XScheme version 0.16 (with IRIS graphics primitives)
> (save "foo")
#t
> (restore "foo")
[ returning to the top level ]
> (* 3 4)
Segmentation violation (core dumped)
A traceback shows
putnumber / xsprint / xlprint / xwrite / xlapply / xlexecute / main
with the program dying at line 278 in xsprint.c at the statement
LVAL fmt = getvalue(s_fixfmt) ;
The following sequence may also be instructive.
XScheme version 0.16 (with IRIS graphics primitives)
> (save "foo")
#t
> (restore "foo")
[ returning to top level ]
> (save "bar")
#t
> (exit)
UNIX% cmp foo bar
foo bar differ: char 94, line 1
My intuition tells me that the two files should be identical. To
give some context, the Personal Iris is a MIPS processor, running
Silicon Graphics' own UNIX, part system V, part BSD 4.2. In this
test, I am running XScheme as "clean" as possible, without the file
"xscheme.ini", without syntax extensions, etc. Bringing up XScheme
with my usual environment, which contains hundreds of graphics
definitions, R. K. Dybvig's syntax extender, etc., etc., causes
XScheme to crash deep in the restore statement itself. I have not
modified the XScheme core, that is, David Betz's code. I have only
added graphics routines in new files.
My hunch is that information about the contents of memory is either
not getting saved correctly or not getting restored correctly, and
the next step seems to be to collect information about the save and
restore processes. I spent a couple of hours desk-checking the
code in xsimage.c for "xlsave" and "xlrestore". There is nothing
obviously wrong. I decided that my next step would be to create
versions of save and restore that deal with a printable format, so
I could see what is being saved and restored, and I prepared myself
to build a memory analyzer that would print out the contents of
memory so I could verify that restore is doing the right thing. I'd
like to avoid doing all this if someone out there has already fixed
the problem.
By the way, save and restore are necessary in my graphics work
because I need to be able to load complex graphics models very
quickly, in compiled form, without going through recompilation.
Please e-mail or phone me if you have a solution, and thanks in
advance.
. . . Dr. Brian Beckman . . . . . . . . . . . . 4800 Oak Grove Drive . . . . .
. . . Computer Graphics Laboratory. . . . . . . Pasadena, CA 91109 . . . . . .
. . . MS 510-202, Jet Propulsion Laboratory . . (818) 397-9207 . . . . . . . .
. . . California Institute of Technology. . . . brian@topaz.jpl.nasa.gov . . .