This is all running on 64-bit debian-testing. We call CHICKEN_initialize() and CHICKEN_run() from the thread the chicken code is running in (not the main thread).
We did not write this C code, and I suspect that disabling threads might not be worth the effort required (not to mention that I'm not exactly a concurrency expert). I will fiddle with the stack size and see if that helps. Thank you for your response! Durward On 2/13/24 12:30, felix.winkelm...@bevuta.com wrote:
APL external email warning: Verify sender felix.winkelm...@bevuta.com before clicking links or attachmentsWe have a (32-bit, fwiw) C program that we are attempting to augment with a CS function. The program runs in ~17 native threads, but our function only runs in one of those threads. We call CHICKEN_initialize(0, 0, 0, C_toplevel); CHICKEN_run(C_toplevel); after the thread is created, but then it goes off into libchicken and segfaults. The last usefully-named function it calls is allocate_vector_2(). Is there a useful way to debug what's going on? The threads exchange messages, though I don't believe any of them should be in the purview of CS's GC. Am I missing something obvious?Is the Chicken code started in the main thread? Also, on what platform is this running? Threads other than the main thread often have a smaller default stack (depending on the OS used), so the thread's stack may be exhausted as the C code generated from Scheme uses the stack as a first level heap and so needs a bit of space. You can also try to run the code with a single native thread for testing to at least have a base that works and continue by enabling threads from there. cheers, felix
-- Durward McDonell durward.mcdon...@jhuapl.edu 240-228-2690 (DC) 443-778-2690 (Balt.)
smime.p7s
Description: S/MIME Cryptographic Signature
