[racket-dev] Another JIT question

From: Jon Zeppieri (zeppieri at gmail.com)
Date: Sat May 11 13:12:54 EDT 2013

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 <mflatt at 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

Posted on the dev mailing list.