<div dir="ltr">Did you try to pull out and simplify read-eval-print-loop until you can get a stand-alone program that crashes? (The impl is in racket/private/misc.rkt.)<div style> Robby</div></div><div class="gmail_extra"> <div class="gmail_quote">On Sat, May 11, 2013 at 12:19 PM, Jon Zeppieri <<a href="mailto:zeppieri@gmail.com" target="_blank">zeppieri@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I did: @@ -1555,9 +1570,9 @@ typedef void (*Scheme_Invoke_Proc)(Scheme_Env *env, intptr_t phase_shift, /* Exploit the fact that these should never be dereferenced: */ #ifndef FIRST_TWO_BYTES_ARE_LEGAL_ADDRESSES -# define MZ_EVAL_WAITING_CONSTANT ((Scheme_Object *)0x2) -# define MZ_APPLY_WAITING_CONSTANT ((Scheme_Object *)0x4) -# define MZ_MULTIPLE_VALUES_CONSTANT ((Scheme_Object *)0x6) +# define MZ_EVAL_WAITING_CONSTANT ((Scheme_Object *)0x4) +# define MZ_APPLY_WAITING_CONSTANT ((Scheme_Object *)0x8) +# define MZ_MULTIPLE_VALUES_CONSTANT ((Scheme_Object *)0xc) #endif <div class="HOEnZb"><div class="h5"> On Sat, May 11, 2013 at 1:16 PM, Matthew Flatt <<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>> wrote: > Wild guess: Did you change the pseudo-values MZ_EVAL_WAITING_CONSTANT > and MZ_MULTIPLE_VALUES_CONSTANT to make sure they're not mistreated as > immediates --- or that a character is not mistreated as a pseduo-value? > > At Sat, 11 May 2013 13:12:54 -0400, Jon Zeppieri wrote: >> These all work: >> >> -> (write #\c) >> #\c >> -> (print #\c) >> #\c >> -> (display #\c) >> c >> >> It really seems to be the case that only functions that return >> characters have problems, and then, only those that return to the repo >> loop. For instance: >> >> -> (write (values #\c)) >> #\c >> -> (values #\c) >> Segmentation fault: 11 >> >> >> On Sat, May 11, 2013 at 11:29 AM, Matthew Flatt <<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>> wrote: >> > The last example seems to be the only one that uses `write', while the >> > others implicitly use `print'. >> > >> > Does >> > >> > (write #\c) >> > >> > crash? How about >> > >> > (print #\c) >> > >> > ? >> > >> > At Fri, 10 May 2013 21:19:25 -0400, Jon Zeppieri wrote: >> >> My experiment with immediately represented characters has gotten to a >> >> state where a non-JIT build passes all tests, but a JIT build fails >> >> (as in, segfaults) on the following program: >> >> >> >> #\c >> >> >> >> It also fails on: >> >> >> >> (integer->char 99) >> >> >> >> and: >> >> >> >> (define (foo x) (integer->char x)) >> >> (foo 99) >> >> >> >> but not on: >> >> >> >> (define (foo x) (write (integer->char x))) >> >> (foo 99) >> >> >> >> So there seems to be a problem returning a character from a jitted >> >> function back to the repl. I haven't been able to figure out where >> >> this occurs, though. gdb's stack traces don't seem very useful for >> >> jitted code, and I can't use Sam's disassembler, because the process >> >> dies. >> >> >> >> Any idea where to look or what debugging tools might be useful? >> >> >> >> -Jon >> >> _________________________ >> >> Racket Developers list: >> >> <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> _________________________ Racket Developers list: <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> </div></div></blockquote></div> </div>