[gopher] UMN gopher client bug resolved?
- To: gopher@complete.org
- Subject: [gopher] UMN gopher client bug resolved?
- From: Brian <brian-keyword-gopher.6f04ff@pongonova.net>
- Date: Sun, 22 Jun 2003 02:32:55 -0500
- Message-id: <[🔎] 20030622073255.GA5116@pongonova.net>
- Reply-to: gopher@complete.org
- In-reply-to: <004e01c2d4ba$fd95be50$01000001@tyamamot2w>
- 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>
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
>
>
>
Reply to: