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
