[racket-dev] repeatable segfault in expander
The below program segfaults the expander, but not the compiler (tested with git HEAD): [samth@punge:~/sw/plt/collects/tests/racket/benchmarks/shootout (master) plt] r Welcome to Racket v5.1.3.9. - (define x '(module m racket (require racket/require) (require (filtered-in (lambda (n) foo) scheme - (compile x) ; reference to an identifier before its definition: foo in module: 'm phase: 1 - (expand x) SIGSEGV MAPERR si_code 1 fault on addr 0x10 Aborted Back trace: (gdb) where #0 0x0012e416 in __kernel_vsyscall () #1 0x001a3e71 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x001a734e in abort () at abort.c:92 #3 0x0822ed2d in fault_handler (sn=11, si=0x876726c, ctx=0x87672ec) at ../../../racket/gc2/sighand.c:118 #4 signal handler called #5 scheme_register_unbound_toplevel (env=0xa51fec70, id=0xa5234950) at ../../../racket/gc2/../src/compenv.c:644 #6 0x082501ee in scheme_bind_syntaxes (where=0x8264d87 local syntax definition, names=0xa51fed20, a=0xa5234f68, exp_env=0xa5734220, insp=0xb7250828, rec=0xa75484d0, drec=0, stx_env=0xa51fec70, rhs_env=0xa51fec70, _pos=0xa75484ec, rename_rib=0xa51fe9f0) at ../../../racket/gc2/../src/compile.c:3623 #7 0x0807e7f4 in local_eval (argc=3, argv=0xa88a6ec8) at ../../../racket/gc2/../src/eval.c:5161 #8 0x002f196a in ?? () #9 0x002e1094 in ?? () #10 0x002dfee4 in ?? () #11 0x002ee0a4 in ?? () #12 0x002e15f4 in ?? () #13 0x08086300 in scheme_do_eval (obj=0x0, num_rands=137223416, rands=0xa7548a14, get_value=1) at ../../../racket/gc2/../src/eval.c:2688 #14 0x0809669f in apply_k () at ../../../racket/gc2/../src/fun.c:1289 #15 0x0809d858 in scheme_top_level_do_worker (k=0x8096610 apply_k, eb=1, new_thread=0, dyn_state=0x0) at ../../../racket/gc2/../src/fun.c:1128 #16 0x0809f016 in scheme_apply_macro (name=0xa51fe278, menv=0xa570c3c8, rator=0xa5721688, code=0xa51fe2f8, env=0xa51fded8, boundname=0x82a7644, rec=0xa7548c38, drec=0, for_set=0) at ../../../racket/gc2/../src/fun.c:1796 #17 0x0824a02c in compile_expand_macro_app (form=0xa51fe258, env=0xa51fded8, rec=0xa7548c38, drec=0, app_position=0) at ../../../racket/gc2/../src/compile.c:4324 #18 scheme_compile_expand_expr (form=0xa51fe258, env=0xa51fded8, rec=0xa7548c38, drec=0, app_position=0) at ../../../racket/gc2/../src/compile.c:4791 #19 0x0824d84e in scheme_expand_expr (form=0xa51fe258, env=0xa51fded8, erec=0xa7548c38, drec=0) at ../../../racket/gc2/../src/compile.c:5257 #20 0x0807d9b6 in expand_k () at ../../../racket/gc2/../src/eval.c:4201 #21 0x0809d858 in scheme_top_level_do_worker (k=0x807d600 expand_k, eb=0, new_thread=0, dyn_state=0x0) at ../../../racket/gc2/../src/fun.c:1128 #22 0x0809da48 in scheme_top_level_do (k=0x807d600 expand_k, eb=0) at ../../../racket/gc2/../src/fun.c:1041 #23 0x08082a4b in do_local_expand (name=0x8264e28 local-expand, for_stx=0, catch_lifts=value optimized out, for_expr=0, argc=3, argv=0xa88a6f64) at ../../../racket/gc2/../src/eval.c:4766 #24 0x08083379 in local_expand (argc=3, argv=0xa88a6f64) at ../../../racket/gc2/../src/eval.c:4814 #25 0x002df5f6 in ?? () #26 0x08086300 in scheme_do_eval (obj=0x0, num_rands=137223352, rands=0xa7549320, get_value=1) at ../../../racket/gc2/../src/eval.c:2688 #27 0x0809669f in apply_k () at ../../../racket/gc2/../src/fun.c:1289 #28 0x0809d858 in scheme_top_level_do_worker (k=0x8096610 apply_k, eb=1, new_thread=0, dyn_state=0x0) at ../../../racket/gc2/../src/fun.c:1128 #29 0x0809f016 in scheme_apply_macro (name=0xa51fdd40, menv=0xa570bd58, rator=0xa570c388, code=0xa51fddc0, env=0xa5736238, boundname=0x82a7644, rec=0xa7549668, drec=0, for_set=0) ---Type return to continue, or q return to quit--- at ../../../racket/gc2/../src/fun.c:1796 #30 0x0824a02c in compile_expand_macro_app (form=0xa5756168, env=0xa5736238, rec=0xa7549668, drec=0, app_position=0) at ../../../racket/gc2/../src/compile.c:4324 #31 scheme_compile_expand_expr (form=0xa5756168, env=0xa5736238, rec=0xa7549668, drec=0, app_position=0) at ../../../racket/gc2/../src/compile.c:4791 #32 0x0824d84e in scheme_expand_expr (form=0xa5756168, env=0xa5736238, erec=0xa7549668, drec=0) at ../../../racket/gc2/../src/compile.c:5257 #33 0x0812fbc0 in do_module_begin_at_phase (form=0xa57361d8, env=0xa57349c0, rec=0xa7549ef4, drec=0, erec=0xa7549ef4, derec=0, phase=0, body_lists=0x82a7f1c, bxs=0xa5736208) at ../../../racket/gc2/../src/module.c:6610 #34 0x08132f7e in do_module_begin (orig_form=0xa5735fd8, env=0xa57349c0, rec=0xa7549ef4, drec=0) at ../../../racket/gc2/../src/module.c:6264 #35 0x08134536 in module_begin_expand (form=0xa5735fd8, env=0xa57349c0, erec=0xa7549ef4, drec=0) at ../../../racket/gc2/../src/module.c:7465 #36 0x0824af63 in scheme_compile_expand_expr (form=0xa5735fd8, env=0xa57349c0, rec=0xa7549ef4, drec=0, app_position=0) at ../../../racket/gc2/../src/compile.c:4614 #37 0x0824d84e in scheme_expand_expr (form=0xa5735fd8, env=0xa57349c0,
Re: [racket-dev] [racket] Code compiled for version ~a, not ~a
At Tue, 20 Sep 2011 00:56:01 -0400, Guillaume Marceau wrote: When I was doing it earlier, I was skipping the 'raco setup -D' step. I was under the impression that the 'raco link' operation updated the necessary info-domain/compiled/cache.rktd files automatically. When I add or remove a directory from PLTCOLLECTS, I don't need to re-run 'raco setup'. So long as the tool's collect has been compiled once before, it loads correctly. I was expecting the same behavior from 'raco link' We can either fix 'raco link's behavior to match my brain, or fix my brain to match raco's. Either-or. When you add a directory to PLTCOLLECTS, then the `info-domain' information is stored with the added directory. When you use `raco link', then the `info-domain' information goes into the default user-specific collection directory or the installation's collection directory (depending on whether it's a user-specific link or an installation-wide link). That's why tool lookup behaves the current way. The intent of the `info-domain' cache is to avoid querying all collections; there's one cache per PLTCOLLECTS element, because the intent was to have a few PLTCOLLECTS paths. In contrast, `raco link' is expected to be used to link many collections, and so all user-specific or installation-specific collections are grouped together. But maybe the choices could be different. For what it's worth, while setting PLTCOLLECTS lets DrRacket see a previously built tool, but it doesn't let the documentation search see the associated documentation. In that case, `raco setup' is needed for both PLTCOLLECTS and `raco link'. Of course, you're using `raco setup -D', so documentation isn't an issue for your purposes, but it's another illustration of how parts of Racket expect `raco setup' for an installed collection. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] repeatable segfault in expander
Fix pushed. At Tue, 20 Sep 2011 11:04:46 -0400, Sam Tobin-Hochstadt wrote: The below program segfaults the expander, but not the compiler (tested with git HEAD): [samth@punge:~/sw/plt/collects/tests/racket/benchmarks/shootout (master) plt] r Welcome to Racket v5.1.3.9. - (define x '(module m racket (require racket/require) (require (filtered-in (lambda (n) foo) scheme - (compile x) ; reference to an identifier before its definition: foo in module: 'm phase: 1 - (expand x) SIGSEGV MAPERR si_code 1 fault on addr 0x10 Aborted Back trace: (gdb) where #0 0x0012e416 in __kernel_vsyscall () #1 0x001a3e71 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x001a734e in abort () at abort.c:92 #3 0x0822ed2d in fault_handler (sn=11, si=0x876726c, ctx=0x87672ec) at ../../../racket/gc2/sighand.c:118 #4 signal handler called #5 scheme_register_unbound_toplevel (env=0xa51fec70, id=0xa5234950) at ../../../racket/gc2/../src/compenv.c:644 #6 0x082501ee in scheme_bind_syntaxes (where=0x8264d87 local syntax definition, names=0xa51fed20, a=0xa5234f68, exp_env=0xa5734220, insp=0xb7250828, rec=0xa75484d0, drec=0, stx_env=0xa51fec70, rhs_env=0xa51fec70, _pos=0xa75484ec, rename_rib=0xa51fe9f0) at ../../../racket/gc2/../src/compile.c:3623 #7 0x0807e7f4 in local_eval (argc=3, argv=0xa88a6ec8) at ../../../racket/gc2/../src/eval.c:5161 #8 0x002f196a in ?? () #9 0x002e1094 in ?? () #10 0x002dfee4 in ?? () #11 0x002ee0a4 in ?? () #12 0x002e15f4 in ?? () #13 0x08086300 in scheme_do_eval (obj=0x0, num_rands=137223416, rands=0xa7548a14, get_value=1) at ../../../racket/gc2/../src/eval.c:2688 #14 0x0809669f in apply_k () at ../../../racket/gc2/../src/fun.c:1289 #15 0x0809d858 in scheme_top_level_do_worker (k=0x8096610 apply_k, eb=1, new_thread=0, dyn_state=0x0) at ../../../racket/gc2/../src/fun.c:1128 #16 0x0809f016 in scheme_apply_macro (name=0xa51fe278, menv=0xa570c3c8, rator=0xa5721688, code=0xa51fe2f8, env=0xa51fded8, boundname=0x82a7644, rec=0xa7548c38, drec=0, for_set=0) at ../../../racket/gc2/../src/fun.c:1796 #17 0x0824a02c in compile_expand_macro_app (form=0xa51fe258, env=0xa51fded8, rec=0xa7548c38, drec=0, app_position=0) at ../../../racket/gc2/../src/compile.c:4324 #18 scheme_compile_expand_expr (form=0xa51fe258, env=0xa51fded8, rec=0xa7548c38, drec=0, app_position=0) at ../../../racket/gc2/../src/compile.c:4791 #19 0x0824d84e in scheme_expand_expr (form=0xa51fe258, env=0xa51fded8, erec=0xa7548c38, drec=0) at ../../../racket/gc2/../src/compile.c:5257 #20 0x0807d9b6 in expand_k () at ../../../racket/gc2/../src/eval.c:4201 #21 0x0809d858 in scheme_top_level_do_worker (k=0x807d600 expand_k, eb=0, new_thread=0, dyn_state=0x0) at ../../../racket/gc2/../src/fun.c:1128 #22 0x0809da48 in scheme_top_level_do (k=0x807d600 expand_k, eb=0) at ../../../racket/gc2/../src/fun.c:1041 #23 0x08082a4b in do_local_expand (name=0x8264e28 local-expand, for_stx=0, catch_lifts=value optimized out, for_expr=0, argc=3, argv=0xa88a6f64) at ../../../racket/gc2/../src/eval.c:4766 #24 0x08083379 in local_expand (argc=3, argv=0xa88a6f64) at ../../../racket/gc2/../src/eval.c:4814 #25 0x002df5f6 in ?? () #26 0x08086300 in scheme_do_eval (obj=0x0, num_rands=137223352, rands=0xa7549320, get_value=1) at ../../../racket/gc2/../src/eval.c:2688 #27 0x0809669f in apply_k () at ../../../racket/gc2/../src/fun.c:1289 #28 0x0809d858 in scheme_top_level_do_worker (k=0x8096610 apply_k, eb=1, new_thread=0, dyn_state=0x0) at ../../../racket/gc2/../src/fun.c:1128 #29 0x0809f016 in scheme_apply_macro (name=0xa51fdd40, menv=0xa570bd58, rator=0xa570c388, code=0xa51fddc0, env=0xa5736238, boundname=0x82a7644, rec=0xa7549668, drec=0, for_set=0) ---Type return to continue, or q return to quit--- at ../../../racket/gc2/../src/fun.c:1796 #30 0x0824a02c in compile_expand_macro_app (form=0xa5756168, env=0xa5736238, rec=0xa7549668, drec=0, app_position=0) at ../../../racket/gc2/../src/compile.c:4324 #31 scheme_compile_expand_expr (form=0xa5756168, env=0xa5736238, rec=0xa7549668, drec=0, app_position=0) at ../../../racket/gc2/../src/compile.c:4791 #32 0x0824d84e in scheme_expand_expr (form=0xa5756168, env=0xa5736238, erec=0xa7549668, drec=0) at ../../../racket/gc2/../src/compile.c:5257 #33 0x0812fbc0 in do_module_begin_at_phase (form=0xa57361d8, env=0xa57349c0, rec=0xa7549ef4, drec=0, erec=0xa7549ef4, derec=0, phase=0, body_lists=0x82a7f1c, bxs=0xa5736208) at ../../../racket/gc2/../src/module.c:6610 #34 0x08132f7e in do_module_begin (orig_form=0xa5735fd8, env=0xa57349c0, rec=0xa7549ef4, drec=0) at ../../../racket/gc2/../src/module.c:6264 #35 0x08134536 in module_begin_expand (form=0xa5735fd8, env=0xa57349c0, erec=0xa7549ef4, drec=0) at ../../../racket/gc2/../src/module.c:7465 #36 0x0824af63 in scheme_compile_expand_expr (form=0xa5735fd8,
[racket-dev] Using places to synchronize with C threads?
It looks like you've done the heavy lifting of creating primitives that can be used to synchronize between OS threads. Is there any way to use place channels to interact between the main Racket thread and an OS thread spawned by an audio library? I don't see any documentation that provides a C interface to the place primitives, and I've learned the hard way that I can't assume that calling racket functions in a C thread is safe. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] error with futures and the compiler
The attached program works fine, and if compiled, it works fine with small inputs: [samth@punge] r tst.rkt 40 /dev/null [samth@punge] r tst.rkt 4000 /dev/null [samth@punge] raco make tst.rkt [samth@punge] r tst.rkt 40 /dev/null But with big inputs, when compiled, it fails: [samth@punge] r tst.rkt 4000 /dev/null compiled/tst_rkt.zo::6943: read (compiled): ill-formed code [../../../racket/gc2/../src/read.c:4751] === context === raise called (with non-exception value) by exception handler: #f; original exception raised: compiled/tst_rkt.zo::6943: read (compiled): ill-formed code [../../../racket/gc2/../src/read.c:4751] internal error: failure during atomic Aborted -- sam th sa...@ccs.neu.edu tst.rkt Description: Binary data _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] error with futures and the compiler
Are the unsafe operations ever misapplied? Robby On Tue, Sep 20, 2011 at 4:27 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: The attached program works fine, and if compiled, it works fine with small inputs: [samth@punge] r tst.rkt 40 /dev/null [samth@punge] r tst.rkt 4000 /dev/null [samth@punge] raco make tst.rkt [samth@punge] r tst.rkt 40 /dev/null But with big inputs, when compiled, it fails: [samth@punge] r tst.rkt 4000 /dev/null compiled/tst_rkt.zo::6943: read (compiled): ill-formed code [../../../racket/gc2/../src/read.c:4751] === context === raise called (with non-exception value) by exception handler: #f; original exception raised: compiled/tst_rkt.zo::6943: read (compiled): ill-formed code [../../../racket/gc2/../src/read.c:4751] internal error: failure during atomic Aborted -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] error with futures and the compiler
Here's a rather smaller version, with the same error: #lang racket/base (require racket/future racket/flonum racket/fixnum racket/cmdline) (define N (command-line #:args (n) (string-number n))) (define (M Ci) (let loop ([Zr 0.0]) (fl+ 0. Ci) (loop 0.0))) (for ([y N]) (future (λ () (let loop-x () (fx 0 N) (M 1.1) (loop-x) On Tue, Sep 20, 2011 at 5:36 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: Removing the unsafe operations doesn't change the error. On Tue, Sep 20, 2011 at 5:29 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Are the unsafe operations ever misapplied? Robby On Tue, Sep 20, 2011 at 4:27 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: The attached program works fine, and if compiled, it works fine with small inputs: [samth@punge] r tst.rkt 40 /dev/null [samth@punge] r tst.rkt 4000 /dev/null [samth@punge] raco make tst.rkt [samth@punge] r tst.rkt 40 /dev/null But with big inputs, when compiled, it fails: [samth@punge] r tst.rkt 4000 /dev/null compiled/tst_rkt.zo::6943: read (compiled): ill-formed code [../../../racket/gc2/../src/read.c:4751] === context === raise called (with non-exception value) by exception handler: #f; original exception raised: compiled/tst_rkt.zo::6943: read (compiled): ill-formed code [../../../racket/gc2/../src/read.c:4751] internal error: failure during atomic Aborted -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] error with futures and the compiler
Fix pushed. At Tue, 20 Sep 2011 17:57:01 -0400, Sam Tobin-Hochstadt wrote: Here's a rather smaller version, with the same error: #lang racket/base (require racket/future racket/flonum racket/fixnum racket/cmdline) (define N (command-line #:args (n) (string-number n))) (define (M Ci) (let loop ([Zr 0.0]) (fl+ 0. Ci) (loop 0.0))) (for ([y N]) (future (λ () (let loop-x () (fx 0 N) (M 1.1) (loop-x) On Tue, Sep 20, 2011 at 5:36 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: Removing the unsafe operations doesn't change the error. On Tue, Sep 20, 2011 at 5:29 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Are the unsafe operations ever misapplied? Robby On Tue, Sep 20, 2011 at 4:27 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: The attached program works fine, and if compiled, it works fine with small inputs: [samth@punge] r tst.rkt 40 /dev/null [samth@punge] r tst.rkt 4000 /dev/null [samth@punge] raco make tst.rkt [samth@punge] r tst.rkt 40 /dev/null But with big inputs, when compiled, it fails: [samth@punge] r tst.rkt 4000 /dev/null compiled/tst_rkt.zo::6943: read (compiled): ill-formed code [../../../racket/gc2/../src/read.c:4751] === context === raise called (with non-exception value) by exception handler: #f; original exception raised: compiled/tst_rkt.zo::6943: read (compiled): ill-formed code [../../../racket/gc2/../src/read.c:4751] internal error: failure during atomic Aborted -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Using places to synchronize with C threads?
Place channels only work between places (os threads spawned using the `place' primitives). Place channels can't be used with an OS thread spawned by an arbitrary C library. but src/racket/src/mzrt.c contains synchronization operations for use between OS threads. Place channels are built on top of the low level wrappers found in src/racket/src/mzrt.c. The wrappers in src/racket/src/mzrt.c can safely be called from any C thread. The downside is that these OS thread synchronization are not exposed in the racket language. The wrappers aren't documented, but they are just a platform portability layer over pthread synchronization primitives. If you are spawning the OS thread, you might want to look at Ryan's sqlite db layer which places the sqlite ffi calls in a second `place' so the interactivity of the main `place' is preserved. If the OS thread is spawned by a third party library, you might be able to use the ffi and the non-blocking mzrt_mutex_trylock call to build what you need. If none of the above work, we might need to build some more infrastructure for synchronizing with OS threads. Kevin On 09/20/2011 12:17 PM, John Clements wrote: It looks like you've done the heavy lifting of creating primitives that can be used to synchronize between OS threads. Is there any way to use place channels to interact between the main Racket thread and an OS thread spawned by an audio library? I don't see any documentation that provides a C interface to the place primitives, and I've learned the hard way that I can't assume that calling racket functions in a C thread is safe. John _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
