----- Original Message ----- From: "Michael Sperber [Mr. Preprocessor]" <sperber(a)informatik.uni-tuebingen.de&gt; To: <xemacs-beta(a)xemacs.org>; "Ben Wing" <ben(a)xemacs.org&gt; Sent: Monday, June 03, 2002 4:21 AM Subject: Internal error: lstream not open lstream) 0x964a700> you can get a backtrace, right?

"Ben Wing" <ben(a)666.com&gt; writes: Here is one such: Signaling: (internal-error "lstream not open" #<INTERNAL OBJECT (XEmacs bug?) (filedesc lstream) 0x8ca5dd8>) kill-buffer(#<buffer " *server news.cs.hut.fi nntp *nntpd**">) nntp-kill-buffer(#<buffer " *server news.cs.hut.fi nntp *nntpd**">) nntp-accept-response() byte-code("..." [nntp-server-buffer alist entry buf process buffer erase-buffer nntp-find-connection-buffer try nntp-try-list-active 0 t "LIST ACTIVE" "GROUP" gnus-buffer-live-p nnheader-report nntp "Connection to %s is closed." throw done nil mapconcat identity " " get-buffer process-status (open run) nntp-kill-buffer process-buffer delq nntp-open-connection "Couldn't open connection to %s" err (byte-code "*« *Æ ,-.«„Ç!ˆÈ /P\"ˆ*Éa«‚ʇ««ŠË \n %ˆÊ‡ƒö

----- Original Message ----- From: "Krishnakumar B" <kitty(a)cs.wustl.edu&gt; To: "Ben Wing" <ben(a)666.com&gt; Cc: <xemacs-beta(a)xemacs.org>; "Ben Wing" <ben(a)xemacs.org>; "Michael Sperber [Mr. Preprocessor]" <sperber(a)informatik.uni-tuebingen.de&gt; Sent: Tuesday, June 04, 2002 4:02 PM Subject: Re: Internal error: lstream not open (filedesc What I'd really like to see is both a C and Lisp backtrace. If you can: [1] change signal_1() in eval.c not to be static. (this is to ensure it doesn't get compiled away into nothingness) [2] run under a debugger and put a breakpoint on signal_1. [3] turn on debug-on-error, e.g. Options->Troubleshooting->Debug On Error. when you get the error, you should be back in the debugger, and you can get a C stacktrace. you can use debug_backtrace() to get a Lisp backtrace, output on stderr or in a separate MS Windows console window. [this should be in the FAQ!] thanks for your help, ben

kitty> It seems to happen when Gnus closes the connection with the NNTP server kitty> after lying idle for a while. I don't get a crash however. YMMV. This is kitty> with CVS updated just a while ago today. It's quite the reverse, actually: the connection times out, but XEmacs doesn't close the process associated with it: apparently Ben snipped some code for the great process-stderr patch. The attached patch should fix it. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla Index: src/event-stream.c =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/event-stream.c,v retrieving revision 1.69 diff -u -r1.69 event-stream.c --- src/event-stream.c 2002/06/20 21:18:29 1.69 +++ src/event-stream.c 2002/06/30 16:28:55 ＠＠ -3104,6 +3104,19 ＠＠ to enable that check, and we do so now. */ kick_status_notify (); } + else + { + /* Deactivate network connection */ + Lisp_Object status = Fprocess_status (p); + if (EQ (status, Qopen) + /* In case somebody changes the theory of whether to + return open as opposed to run for network connection + "processes"... */ + || EQ (status, Qrun)) + update_process_status (p, Qexit, 256, 0); + deactivate_process (p); + status_notify (); + } /* We must call status_notify here to allow the event_stream->unselect_process_cb to be run if appropriate. ＠＠ -3117,8 +3130,8 ＠＠ status_notify() will be called on return to top-level. */ status_notify (); - return; } + return; } case timeout_event: