On Tue, 04 Jun 2019 20:22:48 -0400
Dennis Ogbe <d...@ogbe.net> wrote:

> Hello Daniel,
> 
> thanks for your reply, that's about what I expected. It's not a secret at 
> all---My team and I (a bunch of graduate students) are building an 
> "intelligent" radio network using software-defined radios. The source is not 
> opened--yet--since we are competing as part of a DARPA Grand Challenge [1].
> 
> While I have you here: I am currently fighting a strange bug that crashes my 
> process. I am still in the phase where its occurrences seem random to me, so 
> I can't tell you how to reproduce it, but the crashes seem localized to the 
> if statement in fill_spec_vector in src/c/gfun.d--the call to cl_class_of() 
> crashes with an unrecoverable error "not a lisp object".

what is the object you call cl_class_of on? are you sure it is initialized 
cl_object? you may try attaching gdb to the process (see src/utils/gdbinit for 
useful configuration).
> 
> Since I've seen merge requests like [2] I wanted to try to disable threading, 
> since I won't be using it. But when I compile ecl with
> 
> ./configure --enable-shared --enable-threads=no --enable-boehm=included 
> --with-dffi --enable-debug=yes
> 
> I now crash in cl_boot in a GC function (GC_push_all_eager)! Is building 
> without threads supposed to work or am I trying the wrong thing here? My 
> original problem (the crash in fill_spec_vector) only happens about 1/500 
> times I call the offending function (it's the store function from cl-store), 
> and I am still investigating what the culprit could be. If you have any 
> thoughts--I'd appreciate it!

I've used recently ECL with threads disabled and all seemed to work. I would 
try playing with flags (i.e first allow use autodetected boehm, then skip the 
with-dffi flag if it still doesn't work, then remove enable-shared and at last 
enabl-edebug). If ./configure --disable-threads without any additions still 
crashes then it is indeed problem with this exactly flag.
> 
> Thanks,
> Dennis

Regards,
Daniel
> 
> [1] https://www.spectrumcollaborationchallenge.com/
> [2] https://gitlab.com/embeddable-common-lisp/ecl/merge_requests/100
> 
> Daniel Kochmański <dan...@turtleware.eu> writes:
> 
> > Hello Dennis,
> >
> > On Mon, 2019-06-03 at 20:02 -0400, Dennis Ogbe wrote:
> >> Hello,
> >>
> >> I am working on embedding ECL in a reasonably-sized C++ program and I
> >> have been using v16.1.3 until now, since it seems like this is the
> >> latest official release.
> >
> > Yes, 16.1.3 is the latest official release.
> >>
> >> However, it seems like there is a lot of activity and bug fixes in
> >> the develop branch and I already ran into a few bugs (for example
> >> [1]) that are fixed in develop, but are not in any release. The
> >> documentation also seems to overlap more with the develop branch than
> >> the latest release.
> >
> > That is also true, we work on the next release and we expect to make
> > the new one soon™ (only a few tasks has been left over to implement).
> >>
> >> In your opinion, what is the best and most stable ECL version to use
> >> as of June 2019? I have some reservations about simply picking a
> >> random commit from a dev branch, so I wanted to reach out and ask
> >> y'all directly.
> >
> > There is no good answer for that. While develop branch indeed has many
> > improvements in form of bug fixes and new (dare I say – exciting)
> > features it is only loosely tested. Before each release we work hard to
> > test the release candidate against a big variety of operating systems,
> > architectures and libraries (cl-test-grid is an invaluable help with
> > that) and try to fix regressions. If you feel adventurous just pick
> > develop branch, we do not commit there half-baked things (only stuff
> > which we are certain about or which was a subject of a peer review /
> > testing around the thing being changed) - it is fairly stable. But
> > there is no guarantee that you won't hit some ugly regression we are
> > not aware of yet. Otherwise you may try to live with 16.1.3 until we
> > release the new 16.2.0 version – hopefully withing a few months from
> > now.
> >>
> >> Thanks for all the hard work, this project is great!
> >
> > That's very kind of you to say that. If it is not a secret what are you
> > working on?
> >>
> >> [1] https://gitlab.com/embeddable-common-lisp/ecl/issues/418
> >>
> >
> > Best regards,
> > Daniel


-- 
Daniel Kochmański <dan...@turtleware.eu>

Reply via email to