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 <[email protected]> wrote: > Okay, thank you Matthew. > > On Thu, Sep 17, 2015 at 10:17 PM, Matthew Flatt <[email protected]> > 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 <[email protected]> >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
