all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Concurrency feature, sit-for doesn't work (crashing and unexpected behaviour)
@ 2016-12-11  7:12 Elias Mårtenson
  2016-12-11  9:08 ` Simon Leinen
  0 siblings, 1 reply; 5+ messages in thread
From: Elias Mårtenson @ 2016-12-11  7:12 UTC (permalink / raw)
  To: emacs-devel

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

I have been experimenting with the following code, run from an IELM buffer:

    (make-thread (lambda ()
        (sit-for 5)
        (with-current-buffer "z"
            (insert "foo"))))

I then keep the "z" bufer open in a different window so that I can see what
is going on.

If I type this command and then wait 5 seconds, the buffer get updated just
as I expect.

If I then type the same command again, Emacs crashes after 5 seconds.
Sometimes I have to try more than twice to get Emacs to crash, but it will
inevitably happen.

Also, when the crash doesn't happen, and I keep pressing RET after running
the above form, the insert will happen after much less than 5 seconds.
Sometimes it happens almost immediately. It's like sit-for actually doesn't
wait the correct number of seconds, but rather will just finish as soon as
control is returned to the thread.

Regards,
Elias

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Concurrency feature, sit-for doesn't work (crashing and unexpected behaviour)
  2016-12-11  7:12 Concurrency feature, sit-for doesn't work (crashing and unexpected behaviour) Elias Mårtenson
@ 2016-12-11  9:08 ` Simon Leinen
  2016-12-11 14:38   ` Elias Mårtenson
  2016-12-11 16:16   ` Eli Zaretskii
  0 siblings, 2 replies; 5+ messages in thread
From: Simon Leinen @ 2016-12-11  9:08 UTC (permalink / raw)
  To: Elias Mårtenson; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Concurrency feature, sit-for doesn't work (crashing and unexpected behaviour)
  2016-12-11  9:08 ` Simon Leinen
@ 2016-12-11 14:38   ` Elias Mårtenson
  2016-12-11 16:16   ` Eli Zaretskii
  1 sibling, 0 replies; 5+ messages in thread
From: Elias Mårtenson @ 2016-12-11 14:38 UTC (permalink / raw)
  To: Simon Leinen; +Cc: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Concurrency feature, sit-for doesn't work (crashing and unexpected behaviour)
  2016-12-11  9:08 ` Simon Leinen
  2016-12-11 14:38   ` Elias Mårtenson
@ 2016-12-11 16:16   ` Eli Zaretskii
  2016-12-11 16:40     ` Elias Mårtenson
  1 sibling, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2016-12-11 16:16 UTC (permalink / raw)
  To: Simon Leinen; +Cc: lokedhs, emacs-devel

> From: Simon Leinen <simon.leinen@gmail.com>
> Date: Sun, 11 Dec 2016 10:08:41 +0100
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> 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.

Thanks, but please report these as bugs to the bug tracker.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Concurrency feature, sit-for doesn't work (crashing and unexpected behaviour)
  2016-12-11 16:16   ` Eli Zaretskii
@ 2016-12-11 16:40     ` Elias Mårtenson
  0 siblings, 0 replies; 5+ messages in thread
From: Elias Mårtenson @ 2016-12-11 16:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Simon Leinen, emacs-devel

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

Done. The bug is reported as bug ID 25172
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25172>

Regards,
Elias

On 12 December 2016 at 00:16, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Simon Leinen <simon.leinen@gmail.com>
> > Date: Sun, 11 Dec 2016 10:08:41 +0100
> > Cc: emacs-devel <emacs-devel@gnu.org>
> >
> > 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.
>
> Thanks, but please report these as bugs to the bug tracker.
>

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-12-11 16:40 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-12-11  7:12 Concurrency feature, sit-for doesn't work (crashing and unexpected behaviour) Elias Mårtenson
2016-12-11  9:08 ` Simon Leinen
2016-12-11 14:38   ` Elias Mårtenson
2016-12-11 16:16   ` Eli Zaretskii
2016-12-11 16:40     ` Elias Mårtenson

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.