I've pushed a repair to the git repo, along with your patch to "sconfig.h".
The bug was in the code that patches a return address in the stack to release cached stack-trace information. The JIT-generated code at the patched-in address wasn't saving and restoring the return value correctly. The only remaining mystery is why this bug hasn't caused lots of trouble before. At Mon, 19 Jul 2010 15:36:59 +0100, Tim Brown wrote: > Matt, > > On 17/07/10 16:14, Matthew Flatt wrote: > > Your "sconfig.h" changes look right. My only wild guess at the moment > > is that something else is relying on the C preprocessor setting > > __x86_64__, as opposed to __x86_64. If you add > > > > #define __x86_64__ 1 > > I've added this in amongst the other definitions in my changes to > `sconfig.h'. > > > does that help? > > I'm afraid not. > > During the build (with no switching off of the JIT) I still get: > > ... > gmake[4]: Entering directory > `/usr2/other/plt-5.0/src/SunOS-5.10-amd64/racket/gc2' > env XFORM_PRECOMP=yes ../racketcgc -cqu ../../../racket/gc2/xform.rkt > --setup . --cpp "gcc -m64 -E -I./.. -I../../../racket/gc2/../include > -DNEWGC_BTC_ACCOUNT -DMZ_NO_ICONV -D_LARGEFILE_SOURCE > -D_FILE_OFFSET_BITS=64 " --keep-lines -o xsrc/precomp.h > ../../../racket/gc2/precomp.c > module name resolver: expected result of type <resolved-module-path>; given > #<variable-code> > ... > gmake: *** [all] Error 2 > > I am left with that `racketgcg' in my build directory. It has been built > with the JIT non (more precisely, without me making any effort to switch > JIT off). > > When I run it on the command line, I get: > > > ./racket/racketcgc > Welcome to Racket v5.0 [cgc]. > module name resolver: expected result of type <resolved-module-path>; given > #<bad-value> > module name resolver: expected result of type <resolved-module-path>; given > #<bad-value> > > The error is printed twice on my terminal - for 1 error or 2, I'm not sure. > > If I run: > > > ./racket/racketcgc --no-jit > Welcome to Racket v5.0 [cgc]. > > (exit) > > It all passes off quite smoothly. > > > Something has definitely gone wrong inside `racketcgc', though. I > > imagine that if you set the environment variable PLTNOMZJIT, then 3m > > `racket' will build, but running the resulting `racket' without > > PLTNOMZJIT will produce the same error. > > From what you've written, this behaviour seems to be what you would > expect. > > Is there anything I can do to intercept `racketcgc' before it calls > whatever it calls to throw this error? > > Regards, > > Tim > > -- > Tim Brown <tim.br...@cityc.co.uk> | City Computing Limited | > T: +44 20 8770 2110 | City House, Sutton Park Road | > F: +44 20 8770 2130 | Sutton, Surrey, SM1 2AE, GB | > -----------------------------------------------------------------------| > BEAUTY: What's in your eye when you have a bee in your hand | > -----------------------------------------------------------------------' > City Computing Limited registered in London No. 1767817. > Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE > VAT number 372 8290 34. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
