C FFI & embedding: Calling C function from embedded Chibi Scheme -- nothing happens and crash in gc?

136 views
Skip to first unread message

Michael Labbé

unread,
Jun 3, 2020, 10:19:16 PM6/3/20
to chibi-scheme
Hello, I am beginning to explore embedding Chibi-Scheme.  The following code is supposed to call C function void callme(void) but it never does.  Putting a breakpoint in generated function sexp_callme_stub() shows that it is never called.

Further, the sexp_destroy_context() call has a read access violation in sexp_mark_one() in gc.c.

I am using visual studio 2019 and chibi scheme 0.8.0 compiled in Debug mode with the default options.

Both of these files are linked in to an exe -- there is no .so as part of this scheme.

I would appreciate eyes on to let me know where the error is.

Thanks!

// main.c

#include <stdio.h>
#include <chibi/eval.h>

// (define-c void callme())
void callme(void) {
    puts
("chibi_call");
}
   
int main(int argc, char *argv[]) {
   
   
// init ctx
    sexp ctx
= sexp_make_eval_context(NULL, NULL, NULL, 0, 0);
    sexp_load_standard_env
(ctx, NULL, SEXP_SEVEN);
    sexp_load_standard_ports
(ctx, NULL, stdin, stdout, stderr, 0);

   
// init lib
    sexp_init_library
(ctx, NULL, 3, sexp_context_env(ctx), sexp_version, SEXP_ABI_IDENTIFIER);
    sexp_gc_var1
(obj1);

   
// call it
    puts
("begin call it");
    sexp_gc_preserve1
(ctx, obj1);
    obj1
= sexp_eval_string(ctx, "(callme)", -1, NULL);  // callme is never called
    sexp_gc_release1
(ctx);
    puts
("end call it");

   
// finish up
    sexp_destroy_context
(ctx);

   
return 0;
}
 

/* Automatically generated by chibi-ffi; version: 0.4 */

#include <chibi/eval.h>
/*
types: ()
enums: ()
*/


sexp sexp_callme_stub
(sexp ctx, sexp self, sexp_sint_t n) {
  sexp res
;
  res
= ((callme()), SEXP_VOID);
 
return res;
}


sexp sexp_init_library
(sexp ctx, sexp self, sexp_sint_t n, sexp env, const char* version, const sexp_abi_identifier_t abi) {
  sexp_gc_var3
(name, tmp, op);
 
if (!(sexp_version_compatible(ctx, version, sexp_version)
       
&& sexp_abi_compatible(ctx, abi, SEXP_ABI_IDENTIFIER)))
   
return SEXP_ABI_ERROR;
  sexp_gc_preserve3
(ctx, name, tmp, op);
  op
= sexp_define_foreign(ctx, env, "callme", 0, sexp_callme_stub);
 
if (sexp_opcodep(op)) {
    sexp_opcode_return_type
(op) = SEXP_VOID;
 
}
  sexp_gc_release3
(ctx);
 
return SEXP_VOID;
}




Alex Shinn

unread,
Jun 3, 2020, 10:25:20 PM6/3/20
to chibi-...@googlegroups.com

void callme(void) {
    puts
("chibi_call");
}
Hi Michael,

You should check the output of the sexp_eval_string (obj1), e.g. with

  sexp_debug(ctx, "obj1: ", obj1);

I suspect this will be a dynamic load error.  The problem is the FFI
wrapper lib will not be linked against any library containing callme.

You can put callme in a separate library and link against that, or
inline it in the FFI code:

(c-declare "

void callme(void) {
    puts(\"chibi_call\");
}
")

--
Alex

--
You received this message because you are subscribed to the Google Groups "chibi-scheme" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chibi-scheme...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chibi-scheme/e15dad02-94e6-48f9-888c-d42d0084bcea%40googlegroups.com.

Michael Labbé

unread,
Jun 3, 2020, 10:39:54 PM6/3/20
to chibi-scheme
Thanks for the quick reply, Alex.

sexp_debug() crashes with a read access violation on ctx->value.context.globals which is set to 0x0.  I called it right after sexp_eval_string().

I also tried the c-declare method you suggested but it did not cause a function to be called.

I quickly ported my program to Linux, compiled it with GCC and it worked just fine.

I suspect the issue is related to the compiler choice.

-Mike
To unsubscribe from this group and stop receiving emails from it, send an email to chibi-...@googlegroups.com.

Alex Shinn

unread,
Jun 3, 2020, 10:44:58 PM6/3/20
to chibi-...@googlegroups.com
In that case I'm afraid I can't help you, I don't have access to a windows machine.

The globals should never be NULL, they are initialized in sexp_init_context_globals,
ultimately called by the first sexp_make_context.

--
Alex

To unsubscribe from this group and stop receiving emails from it, send an email to chibi-scheme...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chibi-scheme/00106096-c8a7-4dbc-9c60-d2a4c968d6b9%40googlegroups.com.

Michael Labbé

unread,
Jun 3, 2020, 11:34:58 PM6/3/20
to chibi-scheme
What I can tell you is that ctx->value.context.globals is NULL on return from sexp_make_eval_context in Visual Studio 2019 and not NULL on Linux with GCC.

-Mike

okuoku

unread,
Jun 4, 2020, 12:04:50 AM6/4/20
to chibi-scheme
It looks like same as https://github.com/ashinn/chibi-scheme/issues/645#issuecomment-632270352 Unfortunately I cannot reproduce this yet on my side.

Currently CMake build have known ABI breakage https://github.com/ashinn/chibi-scheme/issues/614#issuecomment-586747300 if the header did not have -DSEXP_USE_GREEN_THREADS=0 defined.

Michael Labbé

unread,
Jun 4, 2020, 12:38:48 AM6/4/20
to chibi-scheme
Disabling green threads, regenerating cmakelists, rebuilding and ensuring the new DLL is being used did not fix the issue for me.

I noticed that you used the commit description "mystery fix".  It may be that there is a memory corruption/stomp bug going on here, and toggling compiler settings is causing it to hide.

-Mike

okuoku

unread,
Jun 4, 2020, 12:50:16 AM6/4/20
to chibi-scheme
> It may be that there is a memory corruption/stomp bug going on here, and toggling compiler settings is causing it to hide.

The commit
was already root-caused; it was turned out SEXP_USE_GREEN_THREADS was part of ABI (I guess it is unexpected though) so we need to use same definition to build chibi-scheme itself and client app.

(chibi-scheme is so POSIX-centric right now and some feature is not ported yet outside of POSIX world; green thread is an example of such feature.)

I suspect something still remain as ABI-factor so we need to keep it same between the interpreter build and client.

Michael Labbé

unread,
Jun 4, 2020, 1:25:56 PM6/4/20
to chibi-scheme
This morning I just rebuilt the code using clang on Windows -- both chibi-scheme itself and my code.  The result is as was previously reported wherein I was using VS 2019.

-Mike

Michael Labbé

unread,
Jun 5, 2020, 1:47:29 PM6/5/20
to chibi-scheme
This issue is worked around by adding

#define SEXP_USE_GREEN_THREADS 0

before #include <chibi/eval.h>.

It is insufficient to simply define the preprocessor directive to 0 when compiling the chibi scheme codebase.

-Mike

Alex Shinn

unread,
Jun 6, 2020, 4:44:44 AM6/6/20
to chibi-...@googlegroups.com
Ah.  Anything feature which is specified or inferred in the Makefile and
also affects the struct layout or globals list also needs to be specified
or inferred for the client project linking to Chibi.  This is not technically
a bug but is going to cause confusion fairly often.

Most of these are debug features which others are unlikely to mess
with, but there are a few auto-detected:

  SEXP_USE_GREEN_THREADS
  SEXP_USE_DL
  SEXP_USE_WEAK_REFERENCES
  SEXP_USE_BOEHM

One thing I can do is avoid conditionally defining these fields or
globals and just not use them.  Another thing is for settings which
affect the ABI to append them to install.h.

--
Alex

--
You received this message because you are subscribed to the Google Groups "chibi-scheme" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chibi-scheme...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chibi-scheme/2df4fb5d-0d09-439a-9b40-51dccccc826do%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages