brian@topaz.jpl.nasa.gov (Brian of ASTD-CP) (08/24/89)
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 . . .