From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Elias_M=C3=A5rtenson?= Newsgroups: gmane.emacs.devel Subject: Re: Concurrency feature, sit-for doesn't work (crashing and unexpected behaviour) Date: Sun, 11 Dec 2016 22:38:27 +0800 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113f461cb16edc054362f039 X-Trace: blaine.gmane.org 1481467184 1853 195.159.176.226 (11 Dec 2016 14:39:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Dec 2016 14:39:44 +0000 (UTC) Cc: emacs-devel To: Simon Leinen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 11 15:39:38 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cG5Hs-0007DF-2F for ged-emacs-devel@m.gmane.org; Sun, 11 Dec 2016 15:39:36 +0100 Original-Received: from localhost ([::1]:55898 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cG5Hu-0000yc-JC for ged-emacs-devel@m.gmane.org; Sun, 11 Dec 2016 09:39:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cG5Hn-0000yJ-Qb for emacs-devel@gnu.org; Sun, 11 Dec 2016 09:39:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cG5Hk-0006eJ-Ij for emacs-devel@gnu.org; Sun, 11 Dec 2016 09:39:31 -0500 Original-Received: from mail-qt0-f172.google.com ([209.85.216.172]:35030) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cG5Hk-0006e8-BK for emacs-devel@gnu.org; Sun, 11 Dec 2016 09:39:28 -0500 Original-Received: by mail-qt0-f172.google.com with SMTP id c47so56084863qtc.2 for ; Sun, 11 Dec 2016 06:39:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sKxxsy2B6Q0u26JITp9OdT9WdsqfBx0CDICaOVE6LYw=; b=l53R8iRVAWry+8ycMEWz1WX1K4oKZvi/gRo+DIQiDe+3yZcQ9oyZwjCj+/x1gHTKjW jgS1k/MhkyRf93T0OHRkhXF0dRr2tyU7cT86UJdXuHC6qrdRopqgBZQDsmeyVXbNzTEK cKAEtSFd0lzUVsiutOri0VZH0DQCEM8on5Q6v+oyuGVDiVr48IT8pa0aLQ012Qpdtjep 3/m3W18vXnd7k5/QoXQeeBnk98PJW5aKLBePzOxPU36v4iZiz5PNsKbgjrSCxevMIrJ1 bSfQ0nufMi+Bk1ynP1J+GSCRdpwfhXEOhxWzBkbCH67rjuZYTflGzRBlxYylVMEq61Od AjeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sKxxsy2B6Q0u26JITp9OdT9WdsqfBx0CDICaOVE6LYw=; b=WVDtvviq72x2oYLDLNSs/zs004UIBSkZYGQrqFtbb1FvO16UkgRDZTs3RbyzSWDRWY figIq7koqSpdvsMbrLfjN9SYHkJQpULhf16vXTr52eylcJfCP9pA5BZmb5niwUK7i2e2 XFz9n8ZkObfp5Lom8587u9xhwErF61hTS+sVnz0CZOikqX90WvnhwvAnjH9cfhM/fqeM Gj6svIFN/LJfN9SLMaIVeln+A9KOqCZf8hNgesXun+XS6nXNtIY5MOEkVHEQ0wALhchd 7bj1Z0NRTL3cKoqyRi4cO/WoFnrOJ8QIJsJbafqvotHmFMJkEbRdRTGggUiwNvljqrK5 Gv4w== X-Gm-Message-State: AKaTC02gPYPPAUBaznXAEsPsApn5GUZe2uFCLgJyQELg8jl9wCgHc2COZk1/bKklyHyTrCR7YAYeUqfQ5rarFA== X-Received: by 10.200.35.46 with SMTP id a43mr86119950qta.20.1481467107567; Sun, 11 Dec 2016 06:38:27 -0800 (PST) Original-Received: by 10.55.110.5 with HTTP; Sun, 11 Dec 2016 06:38:27 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.216.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:210270 Archived-At: --001a113f461cb16edc054362f039 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I compiled Emacs with debugging and took a stack trace at the point of the crash. It seems as the select() call returns EBADF. I don't know much about the internals of Emacs at this level, but it seems to me that sit_for() recursively invokes the command loop. If that is the case, my na=C3=AFve thought is that there are now two command loops at the = same time. That could explain the intermittent behaviour. Does this mean that sit_for() needs to be rewritten to cope with concurrency? And if so, are there other functions that behave the same? Thread 1 "emacs" received signal SIGABRT, Aborted. 0x00007ffff1d952b9 in raise (sig=3D6) at ../sysdeps/unix/sysv/linux/pt-raise.c:35 35 ../sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory. (gdb) where #0 0x00007ffff1d952b9 in raise (sig=3D6) at ../sysdeps/unix/sysv/linux/pt-raise.c:35 #1 0x000000000055fd18 in terminate_due_to_signal (sig=3D6, backtrace_limit=3D40) at emacs.c:394 #2 0x00000000005868ca in emacs_abort () at sysdep.c:2342 #3 0x0000000000665c44 in wait_reading_process_output (time_limit=3D30, nsecs=3D0, read_kbd=3D-1, do_display=3Dtrue, wait_for_cell=3D0, wait_proc=3D0x0, just_wait_proc=3D0) at process.c:5460 #4 0x0000000000423f9c in sit_for (timeout=3D122, reading=3Dtrue, display_option=3D1) at dispnew.c:5763 #5 0x00000000005682bb in read_char (commandflag=3D1, map=3D54013811, prev_event=3D0, used_mouse_menu=3D0x7fffffffdcf9, end_time=3D0x0) at keyboard.c:2725 #6 0x0000000000575849 in read_key_sequence (keybuf=3D0x7fffffffded0, bufsize=3D30, prompt=3D0, dont_downcase_last=3Dfalse, can_return_switch_frame=3Dtrue, fix_current_buffer=3Dtrue, prevent_redisplay=3Dfalse) at keyboard.c:9139 #7 0x0000000000564c41 in command_loop_1 () at keyboard.c:1376 #8 0x0000000000609508 in internal_condition_case ( bfun=3D0x564819 , handlers=3D19632, hfun=3D0x563fe0 ) at eval.c:1336 #9 0x0000000000564520 in command_loop_2 (ignore=3D0) at keyboard.c:1118 #10 0x0000000000608db2 in internal_catch (tag=3D47040, func=3D0x5644f7 , arg=3D0) at eval.c:1101 #11 0x00000000005644c2 in command_loop () at keyboard.c:1097 #12 0x0000000000563bbb in recursive_edit_1 () at keyboard.c:703 #13 0x0000000000563d37 in Frecursive_edit () at keyboard.c:774 #14 0x00000000005619ba in main (argc=3D1, argv=3D0x7fffffffe328) at emacs.c= :1686 (gdb) On 11 December 2016 at 17:08, Simon Leinen wrote: > On Sun, Dec 11, 2016 at 8:12 AM, Elias M=C3=A5rtenson > wrote: > > (make-thread (lambda () > > (sit-for 5) > > (with-current-buffer "z" > > (insert "foo")))) > > Ouch! I'm more or less able to reproduce the problem: When I call this > twice (the second time with the "z" buffer open in a separate frame), > this ends badly. Emacs didn't crash, but became unresponsive. None > of kill{, -1, -15} helped, only kill -9 killed it. Unfortunately I'm > running under Mac OS X (GNU Emacs 26.0.50.3 > (x86_64-apple-darwin15.6.0, X toolkit, Xaw3d scroll bars) of > 2016-12-10 - sorry, that's all my employer tolerates), so I'm not > really able to help debug this. If help is needed I can try under > GNU/Linux in a VM. > -- > Simon. > --001a113f461cb16edc054362f039 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I compiled Emacs with debugging and took a stack trace at = the point of the crash. It seems as the select() call returns EBADF.
I don't know much about the internals of Emacs at this lev= el, but it seems to me that sit_for() recursively invokes the command loop.= If that is the case, my na=C3=AFve thought is that there are now two comma= nd loops at the same time. That could explain the intermittent behaviour.

Does this mean that sit_for() needs to be rewritten= to cope with concurrency? And if so, are there other functions that behave= the same?

Thread 1 "emacs" received = signal SIGABRT, Aborted.
0x00007ffff1d952b9 in raise (sig=3D6) at= ../sysdeps/unix/sysv/linux/pt-raise.c:35
35 ../sysdeps/unix/sysv/linu= x/pt-raise.c: No such file or directory.
(gdb) where
#0= =C2=A00x00007ffff1d952b9 in raise (sig=3D6)
=C2=A0 =C2=A0 at ../= sysdeps/unix/sysv/linux/pt-raise.c:35
#1 =C2=A00x000000000055fd18= in terminate_due_to_signal (sig=3D6, backtrace_limit=3D40)
=C2= =A0 =C2=A0 at emacs.c:394
#2 =C2=A00x00000000005868ca in emacs_ab= ort () at sysdep.c:2342
#3 =C2=A00x0000000000665c44 in wait_readi= ng_process_output (time_limit=3D30, nsecs=3D0,=C2=A0
=C2=A0 =C2= =A0 read_kbd=3D-1, do_display=3Dtrue, wait_for_cell=3D0, wait_proc=3D0x0,= =C2=A0
=C2=A0 =C2=A0 just_wait_proc=3D0) at process.c:5460
<= div>#4 =C2=A00x0000000000423f9c in sit_for (timeout=3D122, reading=3Dtrue, = display_option=3D1)
=C2=A0 =C2=A0 at dispnew.c:5763
#5 = =C2=A00x00000000005682bb in read_char (commandflag=3D1, map=3D54013811,=C2= =A0
=C2=A0 =C2=A0 prev_event=3D0, used_mouse_menu=3D0x7fffffffdcf= 9, end_time=3D0x0)
=C2=A0 =C2=A0 at keyboard.c:2725
#6 = =C2=A00x0000000000575849 in read_key_sequence (keybuf=3D0x7fffffffded0,=C2= =A0
=C2=A0 =C2=A0 bufsize=3D30, prompt=3D0, dont_downcase_last=3D= false,=C2=A0
=C2=A0 =C2=A0 can_return_switch_frame=3Dtrue, fix_cu= rrent_buffer=3Dtrue,=C2=A0
=C2=A0 =C2=A0 prevent_redisplay=3Dfals= e) at keyboard.c:9139
#7 =C2=A00x0000000000564c41 in command_loop= _1 () at keyboard.c:1376
#8 =C2=A00x0000000000609508 in internal_= condition_case (
=C2=A0 =C2=A0 bfun=3D0x564819 <command_loop_1= >, handlers=3D19632, hfun=3D0x563fe0 <cmd_error>)
=C2=A0= =C2=A0 at eval.c:1336
#9 =C2=A00x0000000000564520 in command_loo= p_2 (ignore=3D0) at keyboard.c:1118
#10 0x0000000000608db2 in int= ernal_catch (tag=3D47040,=C2=A0
=C2=A0 =C2=A0 func=3D0x5644f7 <= ;command_loop_2>, arg=3D0) at eval.c:1101
#11 0x00000000005644= c2 in command_loop () at keyboard.c:1097
#12 0x0000000000563bbb i= n recursive_edit_1 () at keyboard.c:703
#13 0x0000000000563d37 in= Frecursive_edit () at keyboard.c:774
#14 0x00000000005619ba in m= ain (argc=3D1, argv=3D0x7fffffffe328) at emacs.c:1686
(gdb)=C2=A0=

On 11 December 2016 at 17:08, Simon Leinen <simon.leinen@gmail= .com> wrote:
On Sun, Dec 11, 2016 at 8:12 AM, Elias M=C3=A5rtenson <lokedhs@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0(make-thread (lambda ()
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(sit-for 5)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(with-current-buffer "z" >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(insert "foo"= ))))

Ouch! I'm more or less able to reproduce the problem: When I cal= l this
twice (the second time with the "z" buffer open in a separate fra= me),
this ends badly.=C2=A0 Emacs didn't crash, but became unresponsive.=C2= =A0 None
of kill{, -1, -15} helped, only kill -9 killed it.=C2=A0 Unfortunately I= 9;m
running under Mac OS X (GNU Emacs 26.0.50.3
(x86_64-apple-darwin15.6.0, X toolkit, Xaw3d scroll bars) of
2016-12-10 - sorry, that's all my employer tolerates), so I'm not really able to help debug this.=C2=A0 If help is needed I can try under
GNU/Linux in a VM.
--
Simon.

--001a113f461cb16edc054362f039--