From: Alan Third <alan@idiocy.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: charles@aurox.ch, 25265@debbugs.gnu.org
Subject: bug#25265: make-thread crashes in OS X 10.6
Date: Tue, 27 Dec 2016 10:44:24 +0000 [thread overview]
Message-ID: <20161227104424.GA45039@breton.holly.idiocy.org> (raw)
In-Reply-To: <83k2alx20b.fsf@gnu.org>
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 <alan@idiocy.org>
> > 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 <return> to continue, or q <return> 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 <return> to continue, or q <return> 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 <really_call_select>, arg=0x7fff5fbfdee8) at alloc.c:5137
#4 0x00000001002a4da6 in thread_select (func=0x1002c62d0 <ns_select>,
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 <return> to continue, or q <return> to quit---
bfun=0x10013a690 <command_loop_1>, handlers=17232,
hfun=0x1001505c0 <cmd_error>) 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 <command_loop_2>, 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
next prev parent reply other threads:[~2016-12-27 10:44 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-24 11:06 bug#25265: make-thread crashes in OS X 10.6 Charles A. Roelli
2016-12-24 17:51 ` Eli Zaretskii
2016-12-25 15:52 ` Eli Zaretskii
2016-12-26 13:09 ` Alan Third
2016-12-26 15:52 ` Eli Zaretskii
2016-12-26 20:56 ` Alan Third
2016-12-27 7:30 ` Eli Zaretskii
2016-12-27 10:44 ` Alan Third [this message]
2016-12-27 11:13 ` Eli Zaretskii
2016-12-28 19:36 ` Alan Third
2016-12-29 17:12 ` Eli Zaretskii
2016-12-30 18:45 ` Alan Third
2016-12-30 21:08 ` Eli Zaretskii
2016-12-30 22:05 ` Alan Third
2016-12-31 9:20 ` Eli Zaretskii
2016-12-31 16:09 ` bug#25265: [PATCH] Rework NS event handling (bug#25265) Alan Third
2016-12-31 16:25 ` Eli Zaretskii
2016-12-31 16:46 ` Alan Third
2017-01-01 15:03 ` Alan Third
2017-01-01 15:42 ` Eli Zaretskii
2017-03-06 20:02 ` bug#25265: make-thread crashes in OS X 10.6 Alan Third
2017-03-08 20:17 ` Charles A. Roelli
2017-03-14 14:49 ` Alan Third
2017-05-02 20:49 ` Alan Third
2017-06-12 19:32 ` Charles A. Roelli
2017-06-13 20:46 ` Alan Third
2017-06-15 18:57 ` Charles A. Roelli
2017-06-15 19:04 ` Alan Third
2017-06-15 19:14 ` Noam Postavsky
2017-06-16 19:45 ` Alan Third
2017-06-16 20:05 ` Noam Postavsky
2017-06-16 20:51 ` Alan Third
2017-06-18 13:05 ` Charles A. Roelli
2017-06-18 14:01 ` Alan Third
2017-06-19 18:34 ` Charles A. Roelli
2017-07-01 12:04 ` Alan Third
2017-07-04 6:59 ` Charles A. Roelli
2017-07-04 12:04 ` npostavs
[not found] ` <20170705193642.GA18888@breton.holly.idiocy.org>
2017-07-06 9:25 ` Charles A. Roelli
2017-07-06 17:10 ` Charles A. Roelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161227104424.GA45039@breton.holly.idiocy.org \
--to=alan@idiocy.org \
--cc=25265@debbugs.gnu.org \
--cc=charles@aurox.ch \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).