Okay, I am here again. No lucky, I cannot make it cooperate with the precision GC, even catching the signal does not work. The `xform` seems buggy in two ways I have encountered: 1. it may eat some module level non-static constants, say, to export `syslog` macros 'facilities', 'severities' and 'open flags' as integer, after `xform`ing the 'open flags' are gone. XFORM_START/END_SKIP will solve it while *_SUSPEND will not. 2. in the foxpipe.c, XFORM_START/END_SKIP causes contracts error because of (caar null).
Finally, I redesigned the records that do not depend on any Scheme_Object and malloc() it as pure data collection. Now the SIGSEGV is out of my source code. But I get something is worse (Racket Version 6.2.0.5): core 'core' of 2574: ----------------- lwp# 1 / thread# 1 -------------------- fffffd7fff27d3ba _lwp_kill () + a fffffd7fff2127b0 raise (6) + 20 fffffd7fff1ecb98 abort () + 98 00000000006fb295 ???????? () fffffd7fff276206 __sighndlr () + 6 fffffd7fff26905b call_user_handler (b, fffffd7fffdf8d48, fffffd7fffdf89e0) + 1db fffffd7fff2693ce sigacthandler (b, fffffd7fffdf8d48, fffffd7fffdf89e0) + 10e --- called from signal handler with signal 11 (SIGSEGV) --- fffffd7fff1d9376 memcpy () + 1936 0000000000702820 propagate_marks () + 120 0000000000702958 propagate_marks_plus_ephemerons () + 18 00000000006fdb8a garbage_collect () + 67a 00000000007009ef collect_now () + 2f 0000000000705122 GC_malloc_one_small_tagged () + 2b2 0000000000617561 scheme_make_output_port () + b1 0000000000630427 scheme_make_byte_string_output_port () + b7 000000000068579c format () + 6c fffffd7ffe7038ef ???????? () fffffd7ffe3f1d6b ???????? () fffffd7ffe7021dd ???????? () fffffd7ffe7021dd ???????? () fffffd7ffe7021dd ???????? () 00000000004b5e55 scheme_do_eval () + 1e55 00000000004cf57d force_values () + cd 00000000004cf707 _apply_native () + f7 00000000004dd8e5 scheme_apply_chaperone () + ca5 00000000004b4a4f scheme_do_eval () + a4f 00000000004b6c47 _scheme_apply_from_native () + 57 fffffd7ffe3418d1 ???????? () fffffd7ffe341f5d ???????? () 00000000004b5e55 scheme_do_eval () + 1e55 00000000004b6e37 _scheme_apply_multi_from_native () + 57 fffffd7ffe710ffc ???????? () 00000000004b5e55 scheme_do_eval () + 1e55 00000000004cbc52 apply_k () + b2 00000000004d3ce8 scheme_top_level_do_worker () + 828 00000000006c705f start_child () + 3ef 00000000006d0c34 make_subprocess () + 204 00000000006d0e74 scheme_thread_w_details () + e4 fffffd7fffdfa0a8 ???????? () ----------------- lwp# 2 / thread# 2 -------------------- ----------------- lwp# 3 / thread# 3 -------------------- ----------------- lwp# 4 / thread# 4 -------------------- ----------------- lwp# 5 / thread# 5 -------------------- ----------------- lwp# 6 / thread# 6 -------------------- ----------------- lwp# 7 / thread# 7 -------------------- ----------------- lwp# 8 / thread# 8 -------------------- and core 'core' of 3008: racket -N sakuyamon -t digivice/sakuyamon.rkt -- izuna gyoudmon.org lo ----------------- lwp# 1 / thread# 1 -------------------- fffffd7fff27d3ba _lwp_kill () + a fffffd7fff2127b0 raise (6) + 20 fffffd7fff1ecb98 abort () + 98 00000000006fb295 ???????? () fffffd7fff276206 __sighndlr () + 6 fffffd7fff26905b call_user_handler (b, fffffd7fffdf8eb8, fffffd7fffdf8b50) + 1db fffffd7fff2693ce sigacthandler (b, fffffd7fffdf8eb8, fffffd7fffdf8b50) + 10e --- called from signal handler with signal 11 (SIGSEGV) --- fffffd7fff1d9376 memcpy () + 1936 0000000000702820 propagate_marks () + 120 0000000000702958 propagate_marks_plus_ephemerons () + 18 00000000006fdb8a garbage_collect () + 67a 00000000007009ef collect_now () + 2f 000000000070601a GC_malloc_atomic () + 22a 000000000050c81b ts_prepare_retry_alloc () + 7b fffffd7ffe715901 ???????? () fffffd7ffe7021dd ???????? () fffffd7ffe7021dd ???????? () fffffd7ffe7021dd ???????? () fffffd7ffe7021dd ???????? () 00000000004b5e55 scheme_do_eval () + 1e55 00000000004cf57d force_values () + cd 00000000004cf707 _apply_native () + f7 00000000004dd8e5 scheme_apply_chaperone () + ca5 00000000004b4a4f scheme_do_eval () + a4f 00000000004b6c47 _scheme_apply_from_native () + 57 fffffd7ffe3418d1 ???????? () fffffd7ffe341f5d ???????? () 00000000004b5e55 scheme_do_eval () + 1e55 00000000004b6e37 _scheme_apply_multi_from_native () + 57 fffffd7ffe710ffc ???????? () 00000000004b5e55 scheme_do_eval () + 1e55 00000000004cbc52 apply_k () + b2 00000000004d3ce8 scheme_top_level_do_worker () + 828 00000000006c705f start_child () + 3ef 00000000006d0c34 make_subprocess () + 204 00000000006d0e74 scheme_thread_w_details () + e4 fffffd7fffdfa0a8 ???????? () ----------------- lwp# 2 / thread# 2 -------------------- ----------------- lwp# 3 / thread# 3 -------------------- ----------------- lwp# 4 / thread# 4 -------------------- ----------------- lwp# 5 / thread# 5 -------------------- ----------------- lwp# 6 / thread# 6 -------------------- ----------------- lwp# 7 / thread# 7 -------------------- ----------------- lwp# 8 / thread# 8 -------------------- Three SSH clients are running in three places separately, all APIs are FFIed without '#:in-orignal-place'. The GC itself crushed in thread #1. I do not make subprocess explicitly and the main place is running with ncurses bindings. On Fri, Sep 18, 2015 at 3:00 AM, WarGrey Gyoudmon Ju <juzhenli...@gmail.com> wrote: > Okay, thank you Matthew. > > On Thu, Sep 17, 2015 at 10:17 PM, Matthew Flatt <mfl...@cs.utah.edu> > wrote: > >> At Thu, 17 Sep 2015 21:29:35 +0800, WarGrey Gyoudmon Ju wrote: >> > On Wed, Sep 16, 2015 at 7:36 PM, Matthew Flatt <mfl...@cs.utah.edu> >> wrote: >> > >> > > But, also, to use either of those, you need to use "xform" to >> adjustthe >> > > C code for GC, or you need to adjust the C code to cooperate >> explicitly >> > > with the GC using MZ_GC_DECL_REG(), etc. Are you using "xform" >> already? >> > > >> > > >> > > More generally, this code looks like something that is more easily >> > > handled by Racket and `ffi/unsafe`, instead of writing new C code. You >> > > still have to be aware of GC issues, but not to the same degree. >> > >> > >> > No, I have not use "xform" yet. This module does work with FFI. It is a >> > chance to learn Racket more deeply. >> > >> > So is explicitly adjust the C code with MZ_GC_DECL_REG() also the right >> way >> > to work with realloc(3)? >> >> Sorry that I forgot to answer the part about replacing libssh2's >> allocation functions. I don't think that's going to work at all, since >> libssh2 doesn't cooperate with the garbage collector. >> >> (If it were just a matter of having a scheme_realloc(), you could >> implement it with scheme_malloc() and memcpy().) >> >> > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
