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.)
Robby On Sat, May 11, 2013 at 12:19 PM, Jon Zeppieri <zeppi...@gmail.com> wrote: > 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 > > > > On Sat, May 11, 2013 at 1:16 PM, Matthew Flatt <mfl...@cs.utah.edu> 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 <mfl...@cs.utah.edu> > 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: > >> >> http://lists.racket-lang.org/dev > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
