[Ecls-list] Segfault in windows using cl-async

[Matthew Mondor]

On Fri, 20 Jun 2014 11:19:00 -0700
Andrew Lyon <orthecreedence at gmail.com> wrote:

> Hello all. I'm the author of cl-async (
> https://github.com/orthecreedence/cl-async) and I'm getting segfaults when
> using it in Windows with ECL (Windows 7 x64, ECL git (52bbd351500), libffi
> 3.0.11, libevent 2.0.21, all compiled via 32bit MinGW gcc 4.8.1. I'm using
> ECL's c compiler for everything (same mingw).
> 
> Everything compiles and runs fine, until I do anything with socket IO, then
> I get a segfault.

> See https://gist.github.com/orthecreedence/a2b666419fe220bfae31 (backtrace
> in comments)

This is probably irrelevant to the issue you're experiencing (please
disreguard if you intended to compile as a test, but not to use the
compiled versions in the above):

I'm not sure that the COMPILE calls do what you intend there...  From
the HyperSpec:

"If the name is nil, the resulting compiled function is returned
directly as the primary value. If a non-nil name is given, then the
resulting compiled function replaces the existing function definition
of name and the name is returned as the primary value; if name is a
symbol that names a macro, its macro function is updated and the name
is returned as the primary value."

So the functions would be compiled but reference to the compiled
versions discarded unless you used funcall on the return value or
assigned it yourself using (setf (symbol-function <symbol>)), which
would be the same as using (compile 'delay) for instance.

> I believe this *may* be related to a bug I reported a while back (
> https://sourceforge.net/p/ecls/bugs/204/) because the backtrace on the
> segfault is completely empty (like in the bug). However it's off that some
> callbacks work and others don't because they all make use of arguments.

My experience with ECL or CFFI on Windows are NIL, unfortunately.

> Instead of just whining and hoping someone fixes it, I'd like to jump in
> and give it a shot myself (unless it's a quick fix that someone can make
> easily). I've been meaning to get to know ECL better because I'm trying to
> use it for a largish project and I think knowing the internals better would
> help me out. I'd also like to eventually get to the point where I can help
> out with various contributions when I have time. I'm ok with C but have
> never touched a compiler before, so any sort of guidance I can get on
> solving this issue would be great.

This list is for that, among other things, you're welcome to ask
questions and we'll help as we can.  Contributions to ECL (and to
ECL-specific CFFI backend) are also welcome.

-- 
Matt