[slim-vim] More details on the socket crash bug
Brad Beveridge
brad.beveridge at gmail.com
Tue Jun 13 14:39:39 CDT 2006
On 13/06/06, Larry Clapp <larry at theclapp.org> wrote:
> On Tue, Jun 13, 2006 at 08:19:10AM -0700, Brad Beveridge wrote:
> > On 13/06/06, Larry Clapp <larry at theclapp.org> wrote:
> > > On Mon, Jun 12, 2006 at 08:40:43AM -0700, Brad Beveridge wrote:
> > > > On 6/12/06, Larry Clapp <larry at theclapp.org> wrote:
> > > > > Okay, I tried your code, and I observed the following behavior:
> > > > >
> > > > > In test.lisp,
> > > > >
> > <SNIP>
> > > > > (or up to 0, or 3, or 7, but rarely if ever the whole 10
> > > > > lines) in the test.lisp lisp scratch buffer, until I pressed
> > > > > at least two keys. I'd press one key (e.g. "h"), and the rest
> > > > > of the lines would show up. I'd press it again, and the
> > > > > cursor would show back up in the test.lisp buffer. Funky.
> > > > Did you see the "oh my god the world has crashed" bug?
> > >
> > > No.
> > Oh. You really want to see that one :)
>
> I think I have now. I've been thrown into the ECL debugger with
> something like "1 is not a list", and some other error messages.
Yup, that's it. Fun for the whole family!
>
> > Well, what I thought was that si_safe_eval was getting called from
> > Vim, and then while some ECL code was running, si_safe_eval would
> > get called again. I thought that this would screw with any global
> > data internal to the ECL interpreter. But I've turned the event
> > loop over in my head and can't see how this can happen. Also I
> > added simple mutex like code to si_safe_eval with a break point if
> > it was called twice and I didn't see it hit. So I have to suspect
> > you are right in blaming the network code. But why does it run well
> > for the easy cases? I would expect it to break in the case where
> > the server doesn't echo back.
>
> I think it goes *something* like this
>
> vim-1: write to socket
> vim-2: read from socket; echo what it read
> vim-1: read what vim-2 echoed to it
> [ repeat above 3 lines an unknown # of times, then ... ]
>
> vim-1: write to socket
> vim-2: read from socket; echo what it read
> vim-1: before write call finished, vim main loop sees data on the
> incoming socket while it's doing an append, and calls the
> ecl network read callback
> [ This happens a few times, and eventually something goes squirrelly ]
>
That is pretty much the way I am leaning right now too. But I don't
see how it can happen, as far as I can tell the mainloop should block
on various file descriptors and be totally single threaded. So how
does the mainloop run before ECL has finised running its code?
I've asked about the async patch on the Vim list, and I've posted to
the ECL list as well. Juan, the maintainer of ECL has expressed more
than just a casual interest, so it'll be nice to have him take a look.
I think he'd quite like to see ECL embedded in an editor.
Cheers
Brad
More information about the slim-vim
mailing list