[slim-vim] More details on the socket crash bug

[Larry Clapp]

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.

> 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 ]

-- Larry