From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Third Newsgroups: gmane.emacs.bugs Subject: bug#25265: make-thread crashes in OS X 10.6 Date: Tue, 27 Dec 2016 10:44:24 +0000 Message-ID: <20161227104424.GA45039@breton.holly.idiocy.org> References: <83r34xxlke.fsf@gnu.org> <83d1ggxayi.fsf@gnu.org> <20161226130917.GA36471@breton.holly.idiocy.org> <8337hay9fl.fsf@gnu.org> <20161226205632.GA36805@breton.holly.idiocy.org> <83k2alx20b.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1482835518 11704 195.159.176.226 (27 Dec 2016 10:45:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Dec 2016 10:45:18 +0000 (UTC) User-Agent: Mutt/1.7.1 (2016-10-04) Cc: charles@aurox.ch, 25265@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 27 11:45:14 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1cLpFj-0001RQ-V4 for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Dec 2016 11:45:08 +0100 Original-Received: from localhost ([::1]:53550 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cLpFo-0008Q7-GA for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Dec 2016 05:45:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cLpFi-0008OW-00 for bug-gnu-emacs@gnu.org; Tue, 27 Dec 2016 05:45:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cLpFe-0002bt-3N for bug-gnu-emacs@gnu.org; Tue, 27 Dec 2016 05:45:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40909) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cLpFe-0002bk-00 for bug-gnu-emacs@gnu.org; Tue, 27 Dec 2016 05:45:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cLpFd-00028C-OU for bug-gnu-emacs@gnu.org; Tue, 27 Dec 2016 05:45:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 27 Dec 2016 10:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25265 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25265-submit@debbugs.gnu.org id=B25265.14828354758143 (code B ref 25265); Tue, 27 Dec 2016 10:45:01 +0000 Original-Received: (at 25265) by debbugs.gnu.org; 27 Dec 2016 10:44:35 +0000 Original-Received: from localhost ([127.0.0.1]:56308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLpFD-00027G-G7 for submit@debbugs.gnu.org; Tue, 27 Dec 2016 05:44:35 -0500 Original-Received: from mail-wj0-f180.google.com ([209.85.210.180]:33700) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLpFB-00026z-4M for 25265@debbugs.gnu.org; Tue, 27 Dec 2016 05:44:33 -0500 Original-Received: by mail-wj0-f180.google.com with SMTP id tq7so78378368wjb.0 for <25265@debbugs.gnu.org>; Tue, 27 Dec 2016 02:44:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=4NSgQEAPu9wmKmW0YslZ8IuSdycXwLTcocYsQ0CowSM=; b=h4vnXZNwThSVhNtV17ZfYIzPbdPVjCk1+W8EDIUYkDdLHxMUxtZmM6IodHXei/cGkI /LAf43/8d1y8kikBk/+cn21KwYoQow7iSn1xziFPLe0vQKShWNHkmvzBiouITOGcnqm+ rtNG/CO4VcrnmeTSPn+Ky2RIxgwUipfwe1ukbBfHOJuz9I/WxxTv+3fN7M1demvD3heE G+z1ogF/HXPd6PM9yll3iwvsLkBn3qvU6CbwuYZuOVCOTllLp4l6fvlx7u+GdjlUnfXQ v4D+HFeattAOxaBE2x5G7h90yfXaHsxeFuYVfIeD0OjDJyRA9HxHYg3YjIbupvNT5+2a KQRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=4NSgQEAPu9wmKmW0YslZ8IuSdycXwLTcocYsQ0CowSM=; b=DYkvFrNToYI71Vp4GKw8ejfT8ykgWM4x7gQqsR7J7q3atpDPBky0E0oJGrWiDj1a56 04fzHD66BHMtgTr75Zkwu2uGk703xz10jnrtMUxzAXkhK25bvOut2l/6DAa0fcVDGfuU 6IBsHfRJgN1YKW9+GNxEJiVfq9ukuTPytXpfVqmAbFZur0HaG1q1GKzYiWuLpCyQnOoI daVz3eKFZDsnvK6cegLq47XayE0WJF3cbzgOfkzaProPN+eb4nMqNRlXw/2cL00r6j1Z 1f5Q56qU8VaGvDUxipQhKkPygGN0SNDrtZRXpEjgMKLZ7ZzA8yaIU2EmVnsGtYO/2NUw PT5w== X-Gm-Message-State: AIkVDXLxk+Io5zZmI9xu66DT5xa8rjqZOLjDbJ0oSV0tycBxFJrttfnteC1/CP59XlWYMg== X-Received: by 10.194.174.229 with SMTP id bv5mr28570389wjc.21.1482835467370; Tue, 27 Dec 2016 02:44:27 -0800 (PST) Original-Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-413d-7770-bc2d-ff97.holly.idiocy.org. [2001:8b0:3f8:8129:413d:7770:bc2d:ff97]) by smtp.gmail.com with ESMTPSA id z9sm6271857wjf.17.2016.12.27.02.44.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Dec 2016 02:44:26 -0800 (PST) Content-Disposition: inline In-Reply-To: <83k2alx20b.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:127490 Archived-At: On Tue, Dec 27, 2016 at 09:30:28AM +0200, Eli Zaretskii wrote: > > Date: Mon, 26 Dec 2016 20:56:32 +0000 > > From: Alan Third > > Cc: charles@aurox.ch, 25265@debbugs.gnu.org > > > > I’m not having any luck with this. My entirely uneducated guess is > > that the main thread can’t access the contents of current_thread. It > > crashes on this line: > > > > while (specpdl_ptr != specpdl + count) > > > > with EXC_BAD_ACCESS. Only three things are being accessed: count, > > which is a function argument, and specpdl and specpdl_ptr are > > #defines to variables within current_thread. > > The loop above is in unbind_to, right? Yes. > > I can’t access anything within current_thread using lldb, but I can > > see current_thread itself. I don’t know if that signifies anything. > > I have bad experience with using lldb (not on OS X, though), so I > don't trust it. Can you use GDB instead? Failing that, is it > possible to just fprintf these values to stderr? OK, I’ve ended up just using printf and it looks like in this thread current_thread is null. GDB says it’s null too. Here’s what I put in just before the while loop: printf("AT: %d\n", current_thread); fflush(stdout); And here’s the output from GDB. You can see where current_thread switches from non‐null to null, just before Emacs hangs: AT: 7842432 AT: 43712208 AT: 43712208 AT: 0 Thread 2 received signal SIGSEGV, Segmentation fault. 0x0000000100200920 in unbind_to (count=0, value=0) at eval.c:3502 3502 while (specpdl_ptr != specpdl + count) (gdb) p current_thread $1 = (struct thread_state *) 0x0 > > I’ll put the complete backtrace at the bottom of this email. > > I don't see any backtraces attached. I’ve actually put it in this time. Sorry about that. > > > [NSApp run]; > > > > > > Can this part and its surrounding code be made thread-safe? > > > > I think this particular method call has to be done *only* from the > > main thread. I imagine that could be a problem. > > It could be a problem, yes. But what does this do, exactly, and why > does it need to be called as part of ns_select? It runs an event loop that picks up all GUI events and then dispatches them. It’s part of NextStep. It’s unclear to me why it’s run in ns_select, but presumably it’s because it needs to be run somewhere and whoever wrote it thought that was a good place. If we need to, I expect we could move it to its own thread. That seems to be a known pattern in the GNUStep/Cocoa world. > Also, why does ns_select sometimes call pselect instead -- is that for > non-interactive or non-GUI sessions or something? It looks that way. It uses it if NSApp isn’t defined, which will happen if Emacs isn’t being run as a GUI application. I’m pretty sure that Emacs doesn’t even use ns_select when it’s run in the terminal, though. It also uses it when timeouts are set to zero. I don’t know what that’s about. The backtrace: Thread 2 received signal SIGSEGV, Segmentation fault. 0x0000000100200933 in unbind_to (count=4, value=0) at eval.c:3499 3499 while (specpdl_ptr != specpdl + count) (gdb) thread apply all bt Thread 13 (Thread 0x1a33 of process 45034): #0 0x00007fffb03594e2 in ?? () #1 0x00007fffb0441791 in ?? () #2 0x0000000000000000 in ?? () Thread 12 (Thread 0x190f of process 45034): #0 0x00007fffb04411e0 in ?? () #1 0x0000000000000000 in ?? () Thread 11 (Thread 0x113f of process 45034): #0 0x00007fffb03594e2 in ?? () #1 0x00007fffb0441791 in ?? () #2 0x0000000000000000 in ?? () Thread 10 (Thread 0x1d03 of process 45034): #0 0x00007fffb035138a in ?? () #1 0x00007fffb03507d7 in ?? () #2 0x0000000000000000 in ?? () Thread 6 (Thread 0x1507 of process 45034): #0 0x00007fffb04411e0 in ?? () #1 0x000000000ee6b280 in ?? () ---Type to continue, or q to quit--- #2 0x000000003b99b0ae in ?? () #3 0x00007000029d1aa0 in ?? () #4 0x00007000029d1a9c in ?? () #5 0x00007000029d17b0 in ?? () #6 0x00007000029d1a30 in ?? () #7 0xe9bfbe3cda25000b in ?? () #8 0x0000000000000000 in ?? () Thread 5 (Thread 0x1407 of process 45034): #0 0x00007fffb0358f4a in ?? () #1 0x0000000100b0cc0e in ?? () #2 0x0000000000000000 in ?? () Thread 4 (Thread 0x120b of process 45034): #0 0x00007fffb0358f4a in ?? () #1 0x00000001002cca9a in -[EmacsApp fd_handler:] (self=0x1016217e0, _cmd=0x100371b45, unused=0x0) at nsterm.m:5512 #2 0x00007fff9c6f6c6d in ?? () #3 0x0000000000000000 in ?? () Thread 2 (Thread 0x1707 of process 45034): #0 0x0000000100200933 in unbind_to (count=4, value=0) at eval.c:3499 #1 0x00000001002c6962 in ns_select (nfds=0, readfds=0x7fff5fbfe5a8, ---Type to continue, or q to quit--- writefds=0x7fff5fbfe528, exceptfds=0x0, timeout=0x7fff5fbfe500, sigmask=0x0) at nsterm.m:4210 #2 0x00000001002a4e3f in really_call_select (arg=0x7fff5fbfdee8) at thread.c:520 #3 0x00000001001d5295 in flush_stack_call_func ( func=0x1002a4dc0 , arg=0x7fff5fbfdee8) at alloc.c:5137 #4 0x00000001002a4da6 in thread_select (func=0x1002c62d0 , max_fds=0, rfds=0x7fff5fbfe5a8, wfds=0x7fff5fbfe528, efds=0x0, timeout=0x7fff5fbfe500, sigmask=0x0) at thread.c:543 #5 0x0000000100274571 in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=0, wait_proc=0x0, just_wait_proc=0) at process.c:5344 #6 0x00000001000092b4 in sit_for (timeout=122, reading=true, display_option=1) at dispnew.c:5763 #7 0x0000000100140c5e in read_char (commandflag=1, map=4337270851, prev_event=0, used_mouse_menu=0x7fff5fbff037, end_time=0x0) at keyboard.c:2729 #8 0x000000010013c0f0 in read_key_sequence (keybuf=0x7fff5fbff360, bufsize=30, prompt=0, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9154 #9 0x000000010013ac32 in command_loop_1 () at keyboard.c:1377 #10 0x000000010020455f in internal_condition_case ( ---Type to continue, or q to quit--- bfun=0x10013a690 , handlers=17232, hfun=0x1001505c0 ) at eval.c:1334 #11 0x00000001001504bc in command_loop_2 (ignore=0) at keyboard.c:1119 #12 0x0000000100203cf8 in internal_catch (tag=43536, func=0x100150490 , arg=0) at eval.c:1100 #13 0x0000000100139be8 in command_loop () at keyboard.c:1098 #14 0x0000000100139a50 in recursive_edit_1 () at keyboard.c:704 #15 0x0000000100139d88 in Frecursive_edit () at keyboard.c:775 #16 0x0000000100137a7d in main (argc=2, argv=0x7fff5fbff9a0) at emacs.c:1690 (gdb) p current_thread.m_specpdl Cannot access memory at address 0x70 (gdb) p current_thread->m_specpdl Cannot access memory at address 0x70 (gdb) -- Alan Third