Date: Sun, 22 Jun 2003 02:32:55 -0500
To: gopher@complete.org
Subject: [gopher] UMN gopher client bug resolved?
Message-ID: <20030622073255.GA5116@pongonova.net>
References: <008701c2d1ca$43452880$01000001@tyamamot2w>
 <20030211221952.GA17086@wile.excelhustler.com>
 <000801c2d22a$4da2ced0$01000001@tyamamot2w>
 <20030212033048.GA80668@gesundheit.complete.org>
 <003b01c2d2b0$c8bd4740$01000001@tyamamot2w>
 <004e01c2d4ba$fd95be50$01000001@tyamamot2w>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <004e01c2d4ba$fd95be50$01000001@tyamamot2w>
User-Agent: Mutt/1.4i
From: Brian <brian-keyword-gopher.6f04ff@pongonova.net>
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org

Does anybody know if this issue was ever resolved?  I run into the
same problems, which pretty much makes the gopher client useless (lots
of dead gopher servers out there!).

Any other gopher clients worth trying if there's not a patch for this?

  --Brian

On Sat, Feb 15, 2003 at 03:25:02PM +0900, Taro Yamamoto wrote:
> 
> I ran gdb to see what's happening. I found a very simple fact: connect()
> didn't return, when accessing an inaccessible server.
> For example, I could not reach the ip address: 128.101.103.43 (found for "
> gopher.tc.umn.edu") at least from my machine. I confirmed it by trying it
> with telnet. It didn't return.
> 
> To stop accessing the server, I input Control-c, as I could not imagine
> anything else.
> Then, it seemed to be caught on the system level, and it damaged the
> terminal and it began beeping, and the cpu started running at full speed. As
> other processes became very slow, I had to kill the process. I didn't know
> why the Control-c interrupt made the disaster. I'm going to test it
> further...
> 
> Regards,
> 
> --Taro
> 
> 
>