Re: Concurrency feature, sit-for doesn't work (crashing and unexpected behaviour)

["Elias Mårtenson" <lokedhs@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3262 bytes --]

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ïve 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=6) 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=6)
    at ../sysdeps/unix/sysv/linux/pt-raise.c:35
#1  0x000000000055fd18 in terminate_due_to_signal (sig=6,
backtrace_limit=40)
    at emacs.c:394
#2  0x00000000005868ca in emacs_abort () at sysdep.c:2342
#3  0x0000000000665c44 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:5460
#4  0x0000000000423f9c in sit_for (timeout=122, reading=true,
display_option=1)
    at dispnew.c:5763
#5  0x00000000005682bb in read_char (commandflag=1, map=54013811,
    prev_event=0, used_mouse_menu=0x7fffffffdcf9, end_time=0x0)
    at keyboard.c:2725
#6  0x0000000000575849 in read_key_sequence (keybuf=0x7fffffffded0,
    bufsize=30, prompt=0, dont_downcase_last=false,
    can_return_switch_frame=true, fix_current_buffer=true,
    prevent_redisplay=false) at keyboard.c:9139
#7  0x0000000000564c41 in command_loop_1 () at keyboard.c:1376
#8  0x0000000000609508 in internal_condition_case (
    bfun=0x564819 <command_loop_1>, handlers=19632, hfun=0x563fe0
<cmd_error>)
    at eval.c:1336
#9  0x0000000000564520 in command_loop_2 (ignore=0) at keyboard.c:1118
#10 0x0000000000608db2 in internal_catch (tag=47040,
    func=0x5644f7 <command_loop_2>, arg=0) 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=1, argv=0x7fffffffe328) at emacs.c:1686
(gdb)

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årtenson <lokedhs@gmail.com>
> 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.
>

[-- Attachment #2: Type: text/html, Size: 4303 bytes --]