GNU bug report logs - #25265
make-thread crashes in OS X 10.6

Previous Next

Full log

Message #26 received at 25265 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: charles <at> aurox.ch, 25265 <at> debbugs.gnu.org
Subject: Re: bug#25265: make-thread crashes in OS X 10.6
Date: Tue, 27 Dec 2016 10:44:24 +0000

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 <at> idiocy.org>
> > Cc: charles <at> aurox.ch, 25265 <at> 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

Previous Next

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