From xemacs-m  Sun Jul 20 13:27:07 1997
Received: from birdland.rhein-neckar.de (root@birdland.rhein-neckar.de [193.197.88.3])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id NAA29767
	for <xemacs-beta@xemacs.org>; Sun, 20 Jul 1997 13:27:05 -0500 (CDT)
Received: from cthulhu.rhein-neckar.de (uucp@localhost) by birdland.rhein-neckar.de (8.8.5/8.8.3) with bsmtp id UAA09512 for xemacs.org!xemacs-beta; Sun, 20 Jul 1997 20:22:26 +0200 (MET DST)
Received: from arthur.rhein-neckar.de by cthulhu.rhein-neckar.de
	via rsmtp with bsmtp
	id <m0wpy6u-0002tOC@cthulhu.rhein-neckar.de>
	for <xemacs-beta@xemacs.org>; Sun, 20 Jul 1997 17:41:24 +0200 (MET DST)
	(Smail-3.2 1996-Jul-4 #30 built 1997-Jun-4)
Received: by arthur.rhein-neckar.de
	via sendmail with stdio
	id <m0wpy1W-0001iNC@arthur.rhein-neckar.de>
	for xemacs-beta@xemacs.org; Sun, 20 Jul 1997 17:35:50 +0200 (CEST)
	(Smail-3.2.0.95 1997-May-7 #5 built 1997-May-28)
To: xemacs-beta@xemacs.org
Subject: Re: Core dump with gnuserv, gpm on "Brussels"
Reply-To: jaeger@informatik.uni-kl.de
References: <u8racyvgn7.fsf@arthur.rhein-neckar.de>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
Date: 20 Jul 1997 17:35:49 +0200
In-Reply-To: Andreas Jaeger's message of "16 Jul 1997 23:19:56 +0200"
Message-ID: <u8sox920tm.fsf@arthur.rhein-neckar.de>
Lines: 58
X-Mailer: Gnus v5.4.63/XEmacs 20.3(beta13) - "Brussels"


>>>>> Andreas Jaeger writes:

 > Hi,

 > I finally tried to track down my already reported problems (at that
 > time with "Stockholm" but the problem is still there) with
 > gnuserv on XEmacs (current version: 20.3b13 "Brussels", Non-Mule for
 > details see last build report), linux-2.0.31-pre2, glibc 2.1 snapshot,
 > XFree 3.3 and gpm version 1.12. 

 > The problem can be reproduced on my system only when gpm is running
 > (!) with the following commands on the console:
 > xemacs -q -no-site-file
 > M-x gnuserv-start

 > gnuclient some-file

 > [...]
 > Please note that the following piece of code from event-Xt.c, line
 > 1746 is stack #4 and might be the problem:
 > #ifdef HAVE_GPM
 >   /* On a stream device (ie: noninteractive), bad things can happen. */
 >   if (EQ (CONSOLE_TYPE (con), Qtty)) {
 >     mousefd = CONSOLE_TTY_MOUSE_FD (con);
 >     if (mousefd >= 0) {
 >       select_filedesc (mousefd, console);
 >     }
 >   }
 > #endif
I've tried again to debug the code and noticed that we call
emacs_Xt_select_console twice: Once, when XEmacs starts, and a second
time when the gnuclient program is started.
The first time doesn't make trouble but at the second time mousefd has 
exactly the same value as at the first time and therefore
filedesc_to_what_closure[mousefd] is in select_filedesc already
initialized and the call fails.

This problem does only occur if XEmacs has GPM support build in and
the gpm server is running. Can anybody reproduce the problem with this 
setup?

 > If I do understand the code, then the call to select_filedesc is only
 > done, when gpm is running - and this call fails if gpm is running and
 > I do a gnuclient.:-(. Sorry, I can't be of any more help for now and
 > hope that  somebody else tries to really track the bug down. Thanks.
I still don't know how to fix it, but I just thought of a kind of counter for
mousefd: increment it for each call of select_filedesc, and decrement
it for deselect_filedesc. I'll leave a fix to the experts and hope my
debugging was of some help.

Btw. the problem still occurs with "Vienna".

Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@alma.student.uni-kl.de
    http://www.student.uni-kl.de/~ajaeger/

