What is the best version of ECL to use right now?

[Daniel Kochmański]

> [...] there are multiple more calls to Lxxstore_object() methods below this
> 
> I am having problems debugging this because I highly doubt that the generic function dispatch mechanism is broken (otherwise *nothing ever* would work, right?) So I think something else is causing this confusion in fill_spec_vector.

It is hard to tell anything without a reproducible test case I could use. Please replace the if/else in fill_spec_vector with:

<<<EOF

    if (ECL_LISTP(spec_type) &&
        !Null(eql_spec = ecl_memql(args[spec_position], spec_type))) {
      argtype[spec_no++] = eql_spec;
    } else {
      printf("XXX: args: %p, spec-pos: %d, args[sp]: %p\n", args, spec_position, args[spec_position]);
      printf("XXX: printing argument\n");
      ecl_print(args[spec_position], ECL_T);
      ecl_terpri(ECL_T);
      printf("XXX: printing argument type\n");
      ecl_print(ecl_type_to_symbol(ecl_t_of(args[spec_position])), ECL_T);
      ecl_terpri(ECL_T);
      printf("XXX: debug information done\n");
      argtype[spec_no++] = cl_class_of(args[spec_position]);
    }

EOF

it could be that the dispatch mechanism misses one particular type, or that you have a dangling pointer, I wouldn't be so sure that all works correct. Please compile ECL with this debug information and when you reproduce the issue send the console output before the error. Note that this may crash before reaching argtype[spec_no++] because we dereference some pointers in the meantime). If it is too verbose, coment out the 'printing argument' part, it may be a big array or something.

> I've compiled it with only the --disable-threads flag now and I still get the same crash in the call to GC_init() in cl_boot(). However, staring the ECL interpreter works fine and embedding ECL into a single-threaded, small example program also works.

Regarding working with threads enabled: ECL enviroment must b e imported on each "C++ world" thread (see examples for how to do that). That is not necessary on ECL with single thread build.

Regarding GC_init – are you certain you do not call it twice for some reason? Or that cl_boot is not called twice? I mildly remember someone had a similar problem and it was due to calling GC_init separately before cl_boot (or immedietely after).
> 
> Could it be that I am missing something when trying to embed ECL in a large C++ codebase? Do I have to worry about the Boehm GC not functioning when most of the program is not designed to use GC_MALLOC? I am also statically linking my lisp code, would that make a difference here?

No, bdwgc should work fine with code which is not libgc aware. You may want to try using libgc shipped with your system. I don't know what your OS is, but OpenBSD has some heavy restrictions for what you can do with memory.
> 


Regards,
Daniel