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

Andrew Lyon orthecreedence at gmail.com
Fri Jun 20 22:44:47 UTC 2014

Hey everyone, it appears after a lot of well-placed (format
t)(force-output) statements, the problem isn't in the callback mechanism,
but instead in tcp-connect function itself (or rather,
cl-async-util::ip-str-to-sockaddr which seems to be overwriting its own
return address somehow). This is another problem entirely and I assume it's
something dumb I'm doing. Sorry for the false report!

On Fri, Jun 20, 2014 at 12:15 PM, Andrew Lyon <orthecreedence at gmail.com>

> Right you are, I edited the example. And as you suspected, the issue still
> happens =]. Any pointers on where I would start look for something like
> adding :stdcall convention support to the compiler/CFFI? Thanks!
> Andrew
> On Fri, Jun 20, 2014 at 11:50 AM, Matthew Mondor <mm_lists at pulsar-zone.net
> > wrote:
>> 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
>> ------------------------------------------------------------------------------
>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>> http://p.sf.net/sfu/hpccsystems
>> _______________________________________________
>> Ecls-list mailing list
>> Ecls-list at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ecls-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20140620/1f7ee3bc/attachment.html>

More information about the ecl-devel mailing list