Re: [clisp-list] errors from socket-status

[<don...@is...>]

Sam Steingold writes:
 > >   $ ./configure --with-module=rawsock --cbc --with-debug build-dir 
 > > seems to work
 > > 
 > >   $ gdb ../build-dir/clisp 
 > >   ...
 > >   warning: not using untrusted file ".gdbinit" 
 > > (I had hoped to use the one in src. so I did cd src before gdb.
 > > I guess that didn't work.)
 > 
 > src/.gdbinit is copied to the build directory by the build process.
 > see
 > http://clisp.cons.org/impnotes/faq.html#faq-debug
would've been worth while to mention that before

 > also, do not forger to pass "CFLAGS=''" to configure to avoid the
 > "-g -O2" idiocy.
The #faq-debug suggests this isn't needed.
In any case, too late now for this run.

 > >   (gdb) break prepare_error 
 > not needed if you follow the FAQ.
I was wondering whether this would also set other break points that I
would not want.
 > >   [../src/stream.d:6143]  
 > >   ignore error  
 > >   UNIX error 104 (ECONNRESET): Connection reset by peer 
 > > I guess above is the line number of an error that was caught and
 > > ignored -- which is good, since I don't want to have to continue
 > > on every intentionally ignored error that arrives before the one
 > > of interest.
 > 
 > yes, except that there is no errors on this line in cvs head.
 > please use cvs head.
Again too late now.  I hope 2.47 will suffice.
This is all on a live server where I don't plan to use cvs head.
 > > So now I wait for a break, I guess, and then do something like
 > >  (gdb) bt
 > > if I understand correctly?
 > 
 > yes.
 > you might also want to examine the relevant local variables.
 > use "xout" and "zout" for lisp objects.
If you can tell me exactly what to type when it breaks, I'll do that.
I'd rather not leave it in the break waiting for further instructions.

 > alas, if this conjecture were true, it would have been easy to reproduce: 
 > connect to a clisp running under gdb, step through to the code above, kill 
 > telnet before listen_char so that the connection is reset, then continue in gdb.
 > alas, no error is raised.

Just killing telnet probably does not result in a reset.
So I think there's still hope.