GNU bug report logs - #5723
23.1.94; make-network-process and emacs hangs

Previous Next

Package: emacs;

Reported by: Leo <sdl.web <at> gmail.com>

Date: Mon, 15 Mar 2010 16:02:01 UTC

Severity: normal

Done: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Leo <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: bug#5723: 23.1.94; make-network-process and emacs hangs
Date: Thu, 18 Mar 2010 09:58:29 +0000
On 2010-03-18 01:57 +0000, YAMAMOTO Mitsuharu wrote:
> The Carbon port and its descendants use polling with SIGALRM to check
> whether C-g is pressed.  The systems without SIGIO (such as Solaris 8)
> work similarly even with X11.  If your case blocks at `connect', then
> it can't be quit with C-g regardless of SYNC_INPUT on those
> ports/systems, because atimer is turned off during the `connect' call.
>
>       immediate_quit = 1;
>       QUIT;
>
>       /* This turns off all alarm-based interrupts; the
> 	 bind_polling_period call above doesn't always turn all the
> 	 short-interval ones off, especially if interrupt_input is
> 	 set.
>
> 	 It'd be nice to be able to control the connect timeout
> 	 though.  Would non-blocking connect calls be portable?
>
> 	 This used to be conditioned by HAVE_GETADDRINFO.  Why?  */
>
>       turn_on_atimers (0);
>
>       ret = connect (s, lres->ai_addr, lres->ai_addrlen);
>       xerrno = errno;
>
>       turn_on_atimers (1);
>
> Again, could you check if it actually blocks at `connect', using GDB?

It looks like it. See:

#0  0x00007fff828c3f66 in connect ()
#1  0x000000010014d715 in Fmake_network_process ()
#2  0x0000000100106a17 in Ffuncall ()
#3  0x0000000100142407 in Fbyte_code ()
#4  0x00000001001062fc in funcall_lambda ()
#5  0x000000010010670f in Ffuncall ()
#6  0x0000000100142407 in Fbyte_code ()
#7  0x0000000100105d60 in Feval ()
#8  0x0000000100108841 in internal_lisp_condition_case ()
#9  0x0000000100141471 in Fbyte_code ()
#10 0x00000001001062fc in funcall_lambda ()
#11 0x000000010010670f in Ffuncall ()
#12 0x000000010010337f in Fcall_interactively ()
#13 0x0000000100106958 in Ffuncall ()
#14 0x0000000100106af6 in call3 ()
#15 0x00000001000935c0 in Fexecute_extended_command ()
#16 0x000000010010697e in Ffuncall ()
#17 0x000000010010337f in Fcall_interactively ()
#18 0x0000000100106958 in Ffuncall ()
#19 0x0000000100106af6 in call3 ()
#20 0x00000001000a125d in command_loop_1 ()
#21 0x0000000100104e27 in internal_condition_case ()
#22 0x00000001000985ee in command_loop_2 ()
#23 0x0000000100104f30 in internal_catch ()
#24 0x0000000100099018 in command_loop ()
#25 0x000000010009948f in recursive_edit_1 ()
#26 0x000000010009962b in Frecursive_edit ()
#27 0x000000010008eea7 in main ()






This bug report was last modified 15 years and 67 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.