bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Fabrice Niessen]

Eli Zaretskii wrote:
>> From: Fabrice Niessen <fni-djc/iPCCuDYQheJpep6IedvLeJWuRmrY@public.gmane.org>
>> 
>> With the following file -- and my configuration file (!):
>> 
>> --8<---------------cut here---------------start------------->8---
>> #+TITLE:     ECM
>> #+LANGUAGE:  en
>> 
>> #+PROPERTY:  eval yes
>> 
>> * Macro
>> 
>> Date at export time: /{{{time(%Y-%m-%d)}}}/.
>> --8<---------------cut here---------------end--------------->8---
>> 
>> Emacs hangs when replacing "yes" by "no" for the "eval" property.
>> 
>> Recipe:
>> - Put cursor after "yes"
>> - Delete "yes"
>> - Type "no"
>> 
>> Symptom: After "n", Emacs hangs, taking 100% of one CPU core.
>
> Thanks, but what do you expect us to do with this report, without any
> information whatsoever regarding your customizations?

I thought that, thanks to the backtrace, you could find the culprit, or
reduce the scope of the search, as you often succeed to do.

> FWIW, the backtrace says Emacs is spell-checking because you have
> Flyspell mode enabled in that buffer.  But that's about all that can
> be said using the information you provided.

My current set of customizations is available at
https://github.com/fniessen/emacs-leuven/blob/master/emacs-leuven.el,
but it's so huge it won't help us.

If you have no idea, the only thing would be a dichotomy of my config
file, but that'll take a while.

Best regards,
Fabrice

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Eli Zaretskii]

> From: Fabrice Niessen <fni-news@pirilampo.org>
> Cc: 19606@debbugs.gnu.org
> Date: Thu, 15 Jan 2015 19:04:13 +0100
> 
> > Thanks, but what do you expect us to do with this report, without any
> > information whatsoever regarding your customizations?
> 
> I thought that, thanks to the backtrace, you could find the culprit, or
> reduce the scope of the search, as you often succeed to do.

But you didn't even show the backtrace from the main (a.k.a. "Lisp")
thread.  Your backtrace is from thread 15, whereas the main thread is
thread 1.  You need to type "thread 1" before "backtrace" to provide
the (possibly) interesting backtrace.

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Dmitry Gutov]

On 01/15/2015 09:14 PM, Eli Zaretskii wrote:

> But you didn't even show the backtrace from the main (a.k.a. "Lisp")
> thread.  Your backtrace is from thread 15, whereas the main thread is
> thread 1.

The output is from 'thread apply all backtrace', AFAICS.

On the other hand, it's not 'bt full' or `xbacktrace', which 
report-emacs-bug asks to call.

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Glenn Morris]

I just want to note that there seems to be a tendency to try and use gdb
to debug Org problems, when debug-on-quit and ctrl-g might work.

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Eli Zaretskii]

> Date: Fri, 16 Jan 2015 00:06:58 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 19606@debbugs.gnu.org
> 
> On 01/15/2015 09:14 PM, Eli Zaretskii wrote:
> 
> > But you didn't even show the backtrace from the main (a.k.a. "Lisp")
> > thread.  Your backtrace is from thread 15, whereas the main thread is
> > thread 1.
> 
> The output is from 'thread apply all backtrace', AFAICS.

No, the output is only from threads 15 and 14.  The command "thread
apply all backtrace" was indeed issued, but Emacs crashed or exited
abnormally while producing the Lisp-level backtrace for thread 14:

  [Inferior 1 (process 1204) exited with code 01]
  (gdb) The program being debugged exited while in a function called from GDB.
  Evaluation of the expression containing the function
  (backtrace_top) will be abandoned.

Therefore that command didn't produce backtraces of the rest of the
threads.

The backtraces shown are not interesting: thread 15 is a thread
created by Windows for attaching the debugger, so it doesn't belong to
Emacs; and thread 14 is the file-notification thread started by
w32notify.c, which simply sleeps waiting for file events.  So the
interesting information from the main thread is not presented, and
it's therefore impossible to tell where and why Emacs hanged.

Typing "thread 1" explicitly right after attaching to the process
might have produce the C-level backtrace for the main thread.  It is a
good thing to do in any case when attaching to Emacs process that's in
trouble.

> On the other hand, it's not 'bt full' or `xbacktrace', which 
> report-emacs-bug asks to call.

"xbacktrace" is automatically called after the C-level backtrace, when
you start GDB from the Emacs's src directory, where .gdbinit file
arranges for that.  That's why you see this part in the OP:

  Lisp Backtrace:
  "redisplay_internal (C function)" (0x1407e78)
  "redisplay" (0x88f254)
  "sit-for" (0x88f3a8)
  "flyspell-check-word-p" (0x88f4f8)
  "byte-code" (0x88f610)
  "flyspell-post-command-hook" (0x88f844)

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Fabrice Niessen <fni-news@pirilampo.org>,  19606@debbugs.gnu.org
> Date: Thu, 15 Jan 2015 16:37:36 -0500
> 
> 
> I just want to note that there seems to be a tendency to try and use gdb
> to debug Org problems, when debug-on-quit and ctrl-g might work.

Very true.

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Fabrice Niessen]

Eli Zaretskii wrote:
>> From: Glenn Morris <rgm-mXXj517/zsQ@public.gmane.org>
>> Cc: Fabrice Niessen <fni-news-TA4HMoP+1wHrZ44/DZwexQ@public.gmane.org>,  19606-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org
>> Date: Thu, 15 Jan 2015 16:37:36 -0500
>> 
>> 
>> I just want to note that there seems to be a tendency to try and use
>> gdb to debug Org problems, when debug-on-quit and ctrl-g might work.
>
> Very true.

As it doesn't seem obvious, let me state explicitly that C-g does
nothing; Emacs is hung and does not answer anymore to anything...

Is there an alternative to GDB in such cases?

Best regards,
Fabrice

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Fabrice Niessen]

Eli Zaretskii wrote:
>> Date: Fri, 16 Jan 2015 00:06:58 +0300
>> From: Dmitry Gutov <dgutov-o+MxOtu4lMCHXe+LvDLADg@public.gmane.org>
>> CC: 19606-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org
>> 
>> On 01/15/2015 09:14 PM, Eli Zaretskii wrote:
>> 
>>> But you didn't even show the backtrace from the main (a.k.a. "Lisp")
>>> thread.  Your backtrace is from thread 15, whereas the main thread
>>> is thread 1.
>> 
>> The output is from 'thread apply all backtrace', AFAICS.
>
> No, the output is only from threads 15 and 14.  The command "thread
> apply all backtrace" was indeed issued, but Emacs crashed or exited
> abnormally while producing the Lisp-level backtrace for thread 14:
>
>   [Inferior 1 (process 1204) exited with code 01]
>   (gdb) The program being debugged exited while in a function called
>   from GDB.
>   Evaluation of the expression containing the function
>   (backtrace_top) will be abandoned.
>
> Therefore that command didn't produce backtraces of the rest of the
> threads.
>
> The backtraces shown are not interesting: thread 15 is a thread
> created by Windows for attaching the debugger, so it doesn't belong to
> Emacs; and thread 14 is the file-notification thread started by
> w32notify.c, which simply sleeps waiting for file events.  So the
> interesting information from the main thread is not presented, and
> it's therefore impossible to tell where and why Emacs hanged.
>
> Typing "thread 1" explicitly right after attaching to the process
> might have produce the C-level backtrace for the main thread.  It is a
> good thing to do in any case when attaching to Emacs process that's in
> trouble.
>
>> On the other hand, it's not 'bt full' or `xbacktrace', which 
>> report-emacs-bug asks to call.
>
> "xbacktrace" is automatically called after the C-level backtrace, when
> you start GDB from the Emacs's src directory, where .gdbinit file
> arranges for that.  That's why you see this part in the OP:
>
>   Lisp Backtrace:
>   "redisplay_internal (C function)" (0x1407e78)
>   "redisplay" (0x88f254)
>   "sit-for" (0x88f3a8)
>   "flyspell-check-word-p" (0x88f4f8)
>   "byte-code" (0x88f610)
>   "flyspell-post-command-hook" (0x88f844)

OK, so I just reproduced the problem once again, then:

- tried to C-g in Emacs: impossible!
- launched GDB
- source ~/.gdbinit
- thread 1
- thread apply all backtrace

Still, the backtrace is not as long as normal, and I don't get any GDB
prompt anymore!

I tried to C-c in the shell window, as well without success...

What can I do to provide you with more context?

Best regards,
Fabrice

Re: bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Eric Abrahamsen]

Fabrice Niessen <fni-news@pirilampo.org>
writes:

> Eli Zaretskii wrote:
>>> From: Glenn Morris <rgm@gnu.org>
>>> Cc: Fabrice Niessen <fni-news@pirilampo.org>,  19606-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org
>>> Date: Thu, 15 Jan 2015 16:37:36 -0500
>>> 
>>> 
>>> I just want to note that there seems to be a tendency to try and use
>>> gdb to debug Org problems, when debug-on-quit and ctrl-g might work.
>>
>> Very true.
>
> As it doesn't seem obvious, let me state explicitly that C-g does
> nothing; Emacs is hung and does not answer anymore to anything...
>
> Is there an alternative to GDB in such cases?
>
> Best regards,
> Fabrice

I've had this problem before, also un-quittable, and have gotten a
backtrace and regained control by sending SIGUSR2 to the emacs process.
The backtrace indicates some conflict with flyspell-mode, same as
you.

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Fabrice Niessen]

Fabrice Niessen wrote:
> OK, so I just reproduced the problem once again, then:
>
> - tried to C-g in Emacs: impossible!
> - launched GDB
> - source ~/.gdbinit
> - thread 1
> - thread apply all backtrace
>
> Still, the backtrace is not as long as normal, and I don't get any GDB
> prompt anymore!
>
> I tried to C-c in the shell window, as well without success...
>
> What can I do to provide you with more context?

You can see all those steps on the video
http://screencast.com/t/umVUFo6h6toS.

Re: bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Fabrice Niessen]

Eric Abrahamsen wrote:
> Fabrice Niessen writes:
>> Eli Zaretskii wrote:
>>>> From: Glenn Morris <rgm-mXXj517/zsQ@public.gmane.org>
>>>> Cc: Fabrice Niessen <fni-news-TA4HMoP+1wHrZ44/DZwexQ@public.gmane.org>,  19606-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org
>>>> Date: Thu, 15 Jan 2015 16:37:36 -0500
>>>> 
>>>> I just want to note that there seems to be a tendency to try and
>>>> use gdb to debug Org problems, when debug-on-quit and ctrl-g might
>>>> work.
>>>
>>> Very true.
>>
>> As it doesn't seem obvious, let me state explicitly that C-g does
>> nothing; Emacs is hung and does not answer anymore to anything...
>
> I've had this problem before, also un-quittable, and have gotten
> a backtrace and regained control by sending SIGUSR2 to the emacs
> process.  The backtrace indicates some conflict with flyspell-mode,
> same as you.

On Cygwin (I'm on Windows), that does not seem to work:

  kill -10 <PID>
  kill -USR2 <PID>

all answer that there is "no such process" -- while, as you can see in
http://screencast.com/t/EFDJIIu7, I typed the right PID of the hung
Emacs process...

Best regards,
Fabrice

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Eli Zaretskii]

> From: Fabrice Niessen <fni-news@pirilampo.org>
> Cc: 19606@debbugs.gnu.org
> Date: Fri, 16 Jan 2015 12:16:26 +0100
> 
> Eli Zaretskii wrote:
> >> From: Glenn Morris <rgm@gnu.org>
> >> Cc: Fabrice Niessen <fni-news@pirilampo.org>,  19606@debbugs.gnu.org
> >> Date: Thu, 15 Jan 2015 16:37:36 -0500
> >> 
> >> 
> >> I just want to note that there seems to be a tendency to try and use
> >> gdb to debug Org problems, when debug-on-quit and ctrl-g might work.
> >
> > Very true.
> 
> As it doesn't seem obvious, let me state explicitly that C-g does
> nothing;

With or without setting debug-on-quit non-nil?

> Is there an alternative to GDB in such cases?

No.

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Eli Zaretskii]

> From: Fabrice Niessen <fni-news@pirilampo.org>
> Cc: 19606@debbugs.gnu.org
> Date: Fri, 16 Jan 2015 12:27:16 +0100
> 
> OK, so I just reproduced the problem once again, then:
> 
> - tried to C-g in Emacs: impossible!
> - launched GDB
> - source ~/.gdbinit
> - thread 1
> - thread apply all backtrace
> 
> Still, the backtrace is not as long as normal, and I don't get any GDB
> prompt anymore!

Can you show what this produced.

> I tried to C-c in the shell window, as well without success...
> 
> What can I do to provide you with more context?

Try this instead:

 - reproduce the problem
 - attach GDB, but do NOT "source ~/.gdbinit"
 - thread 1
 - backtrace

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Fabrice Niessen]

Eli Zaretskii wrote:
>> From: Fabrice Niessen <fni-news-TA4HMoP+1wHrZ44/DZwexQ@public.gmane.org>
>> Cc: 19606-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org
>> Date: Fri, 16 Jan 2015 12:16:26 +0100
>> 
>> Eli Zaretskii wrote:
>>>> From: Glenn Morris <rgm-mXXj517/zsQ@public.gmane.org>
>>>> Cc: Fabrice Niessen <fni-news-TA4HMoP+1wHrZ44/DZwexQ@public.gmane.org>,  19606-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org
>>>> Date: Thu, 15 Jan 2015 16:37:36 -0500
>>>> 
>>>> I just want to note that there seems to be a tendency to try and use
>>>> gdb to debug Org problems, when debug-on-quit and ctrl-g might work.
>>>
>>> Very true.
>> 
>> As it doesn't seem obvious, let me state explicitly that C-g does
>> nothing;
>
> With or without setting debug-on-quit non-nil?

In both cases.

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Fabrice Niessen]

Eli Zaretskii wrote:
>> From: Fabrice Niessen <fni-news-TA4HMoP+1wHrZ44/DZwexQ@public.gmane.org>
>> Cc: 19606-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org
>> Date: Fri, 16 Jan 2015 12:27:16 +0100
>> 
>> OK, so I just reproduced the problem once again, then:
>> 
>> - tried to C-g in Emacs: impossible!
>> - launched GDB
>> - source ~/.gdbinit
>> - thread 1
>> - thread apply all backtrace
>> 
>> Still, the backtrace is not as long as normal, and I don't get any GDB
>> prompt anymore!
>
> Can you show what this produced.

It's in the video, but I forgot to copy it.

I just re-did the ABOVE for a new Emacs session, to get something
similar to the results in the video.

--8<---------------cut here---------------start------------->8---
$ gdb -p 5676
GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
/cygdrive/d/Users/fni/.gdbinit:19: Error in sourced command file:
No symbol table is loaded.  Use the "file" command.
Attaching to process 5676
[New Thread 5676.0x4bbc]
[New Thread 5676.0x4b30]
[New Thread 5676.0x3374]
[New Thread 5676.0x1878]
[New Thread 5676.0x4634]
[New Thread 5676.0x61b0]
[New Thread 5676.0x2564]
[New Thread 5676.0x2d4c]
[New Thread 5676.0x155c]
[New Thread 5676.0x4ac0]
[New Thread 5676.0x5998]
[New Thread 5676.0x4be4]
[New Thread 5676.0x369c]
[New Thread 5676.0x3c7c]
Reading symbols from /cygdrive/c/Program Files (x86)/emacs-24.4/bin/emacs.exe...done.
0x77d3f925 in ntdll!DbgBreakPoint ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb) source ~/.gdbinit
Warning: /cygdrive/c/Program Files (x86)/emacs-24.4/bin/../lwlib: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
TERM = xterm-256color
Breakpoint 1 at 0x109436d: file ../../emacs-24.4/src/emacs.c, line 350.
Temporary breakpoint 2 at 0x10aa8ce: file ../../emacs-24.4/src/sysdep.c, line 850.
(gdb) thread 1
[Switching to thread 1 (Thread 5676.0x4bbc)]
#0  find_interval (tree=0x6d129a4, position=138)
    at ../../emacs-24.4/src/intervals.c:690
(gdb) 690       ../../emacs-24.4/src/intervals.c: No such file or directory.

[Switching to thread 1 (Thread 5676.0x4bbc)]
#0  find_interval (tree=0x6d129a4, position=138)
    at ../../emacs-24.4/src/intervals.c:690
690     in ../../emacs-24.4/src/intervals.c
(gdb) thread apply all backtrace

Thread 14 (Thread 5676.0x3c7c):
#0  0x77d3f925 in ntdll!DbgBreakPoint ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#1  0x77dadb8c in ntdll!DbgUiRemoteBreakin ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#2  0x95b35457 in ?? ()
#3  0x00000000 in ?? ()

Lisp Backtrace:
"redisplay_internal (C function)" (0x1407e78)
"redisplay" (0x88f254)
"sit-for" (0x88f3a8)
"flyspell-check-word-p" (0x88f4f8)
"byte-code" (0x88f610)
"flyspell-post-command-hook" (0x88f844)

Thread 13 (Thread 5676.0x369c):
#0  0x77d3de5c in ntdll!ZwDelayExecution ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#1  0x755311f8 in SleepEx () from /cygdrive/c/Windows/SYSTEM32/KERNELBASE.dll
#2  0x00000001 in ?? ()
#3  0x6f5aff20 in ?? ()
#4  0x0114ab1e in watch_worker (arg=0x3bf5c00)
    at ../../emacs-24.4/src/w32notify.c:278
#5  0x775b86e3 in KERNEL32!BaseThreadInitThunk ()
   from /cygdrive/c/Windows/SYSTEM32/KERNEL32.DLL
#6  0x77d6be19 in ntdll!RtlInitializeExceptionChain ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#7  0x77d6bdec in ntdll!RtlInitializeExceptionChain ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#8  0x00000000 in ?? ()
[Thread 5676.0x3c7c exited with code 0]
--8<---------------cut here---------------end--------------->8---

>> I tried to C-c in the shell window, as well without success...
>> 
>> What can I do to provide you with more context?
>
> Try this instead:
>
>  - reproduce the problem
>  - attach GDB, but do NOT "source ~/.gdbinit"
>  - thread 1
>  - backtrace

Here is it (http://screencast.com/t/o9BVgY7hWN):

--8<---------------cut here---------------start------------->8---
$ gdb -p 17252
GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
/cygdrive/d/Users/fni/.gdbinit:19: Error in sourced command file:
No symbol table is loaded.  Use the "file" command.
Attaching to process 17252
[New Thread 17252.0x44f0]
[New Thread 17252.0x1404]
[New Thread 17252.0x1658]
[New Thread 17252.0x53ac]
[New Thread 17252.0x5634]
[New Thread 17252.0xd54]
[New Thread 17252.0x485c]
[New Thread 17252.0x4e34]
[New Thread 17252.0x3484]
[New Thread 17252.0x3f3c]
[New Thread 17252.0xe38]
[New Thread 17252.0x1730]
[New Thread 17252.0x10dc]
[New Thread 17252.0x5fc0]
[New Thread 17252.0x38a8]
Reading symbols from /cygdrive/c/Program Files (x86)/emacs-24.4/bin/emacs.exe...done.
0x77d3f925 in ntdll!DbgBreakPoint ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb) thread 1
[Switching to thread 1 (Thread 17252.0x44f0)]
#0  0x01142191 in Fnext_single_property_change (position=position@entry=540,
    prop=62947906, object=118795585, limit=limit@entry=1356)
    at ../../emacs-24.4/src/textprop.c:1034
1034    ../../emacs-24.4/src/textprop.c: No such file or directory.
(gdb) backtrace
#0  0x01142191 in Fnext_single_property_change (position=position@entry=540,
    prop=62947906, object=118795585, limit=limit@entry=1356)
    at ../../emacs-24.4/src/textprop.c:1034
#1  0x0102e54f in handle_invisible_prop (it=0x889a14)
    at ../../emacs-24.4/src/xdisp.c:4379
#2  0x01022e18 in handle_stop (it=it@entry=0x889a14)
    at ../../emacs-24.4/src/xdisp.c:3478
#3  0x010231e9 in next_element_from_string (it=0x889a14)
    at ../../emacs-24.4/src/xdisp.c:7915
#4  0x01025e1c in get_next_display_element (it=it@entry=0x889a14)
    at ../../emacs-24.4/src/xdisp.c:6925
#5  0x0102b00f in display_line (it=<optimized out>)
    at ../../emacs-24.4/src/xdisp.c:20183
#6  0x00000000 in ?? ()
(gdb)
--8<---------------cut here---------------end--------------->8---

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Eli Zaretskii]

> From: Fabrice Niessen <fni-news@pirilampo.org>
> Cc: dgutov@yandex.ru,  19606@debbugs.gnu.org
> Date: Fri, 16 Jan 2015 13:04:00 +0100
> 
> (gdb) thread 1
> [Switching to thread 1 (Thread 17252.0x44f0)]
> #0  0x01142191 in Fnext_single_property_change (position=position@entry=540,
>     prop=62947906, object=118795585, limit=limit@entry=1356)
>     at ../../emacs-24.4/src/textprop.c:1034
> 1034    ../../emacs-24.4/src/textprop.c: No such file or directory.
> (gdb) backtrace
> #0  0x01142191 in Fnext_single_property_change (position=position@entry=540,
>     prop=62947906, object=118795585, limit=limit@entry=1356)
>     at ../../emacs-24.4/src/textprop.c:1034
> #1  0x0102e54f in handle_invisible_prop (it=0x889a14)
>     at ../../emacs-24.4/src/xdisp.c:4379
> #2  0x01022e18 in handle_stop (it=it@entry=0x889a14)
>     at ../../emacs-24.4/src/xdisp.c:3478
> #3  0x010231e9 in next_element_from_string (it=0x889a14)
>     at ../../emacs-24.4/src/xdisp.c:7915
> #4  0x01025e1c in get_next_display_element (it=it@entry=0x889a14)
>     at ../../emacs-24.4/src/xdisp.c:6925
> #5  0x0102b00f in display_line (it=<optimized out>)
>     at ../../emacs-24.4/src/xdisp.c:20183
> #6  0x00000000 in ?? ()

Looks like an infloop due to display or overlay strings with text
properties.  Can you reproduce this in an unoptimized build?

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Fabrice Niessen]

Eli Zaretskii wrote:>> From: Fabrice Niessen <fni-news-TA4HMoP+1wHrZ44/DZwexQ@public.gmane.org>
>> Cc: dgutov-o+MxOtu4lMCHXe+LvDLADg@public.gmane.org,  19606-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org
>> Date: Fri, 16 Jan 2015 13:04:00 +0100
>> 
>> (gdb) thread 1
>> [Switching to thread 1 (Thread 17252.0x44f0)]
>> #0  0x01142191 in Fnext_single_property_change (position=position@entry=540,
>>     prop=62947906, object=118795585, limit=limit@entry=1356)
>>     at ../../emacs-24.4/src/textprop.c:1034
>> 1034    ../../emacs-24.4/src/textprop.c: No such file or directory.
>> (gdb) backtrace
>> #0  0x01142191 in Fnext_single_property_change (position=position@entry=540,
>>     prop=62947906, object=118795585, limit=limit@entry=1356)
>>     at ../../emacs-24.4/src/textprop.c:1034
>> #1  0x0102e54f in handle_invisible_prop (it=0x889a14)
>>     at ../../emacs-24.4/src/xdisp.c:4379
>> #2  0x01022e18 in handle_stop (it=it@entry=0x889a14)
>>     at ../../emacs-24.4/src/xdisp.c:3478
>> #3  0x010231e9 in next_element_from_string (it=0x889a14)
>>     at ../../emacs-24.4/src/xdisp.c:7915
>> #4  0x01025e1c in get_next_display_element (it=it@entry=0x889a14)
>>     at ../../emacs-24.4/src/xdisp.c:6925
>> #5  0x0102b00f in display_line (it=<optimized out>)
>>     at ../../emacs-24.4/src/xdisp.c:20183
>> #6  0x00000000 in ?? ()
>
> Looks like an infloop due to display or overlay strings with text
> properties.  Can you reproduce this in an unoptimized build?

Sure, if you can point me to such a version I can download.

Best regards,
Fabrice

Re: bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Achim Gratz]

Fabrice Niessen writes:
> On Cygwin (I'm on Windows), that does not seem to work:
>
>   kill -10 <PID>
>   kill -USR2 <PID>

Cygwin kill only works with Cygwin processes, while your backtrace is
from a Windows Emacs.  The problem of the incomplete traces might also
be related to your attempt to attach a Cygwin gdb to a Windows process.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Eli Zaretskii]

> From: Fabrice Niessen <fni-news@pirilampo.org>
> Cc: dgutov@yandex.ru,  19606@debbugs.gnu.org
> Date: Fri, 16 Jan 2015 19:31:38 +0100
> 
> > Looks like an infloop due to display or overlay strings with text
> > properties.  Can you reproduce this in an unoptimized build?
> 
> Sure, if you can point me to such a version I can download.

Sorry, I don't.  But maybe someone else does.

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Glenn Morris]

The alternative is to supply a minimum reproducible recipe starting with
emacs -Q, then someone else can debug it.

BTW, it's a nice gesture to provide screencasts, but I don't think
anyone developing Emacs finds them particularly useful for debugging, so
no need to keep providing those AFAICS.

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Dani Moncayo]

> > Looks like an infloop due to display or overlay strings with text
> > properties.  Can you reproduce this in an unoptimized build?
>
> Sure, if you can point me to such a version I can download.

https://sourceforge.net/projects/emacs-bin/files/snapshots/debug/

HTH

-- 
Dani Moncayo

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Fabrice Niessen]

Eli Zaretskii wrote:
>> From: Fabrice Niessen <fni-news-TA4HMoP+1wHrZ44/DZwexQ@public.gmane.org>
>> Cc: dgutov-o+MxOtu4lMCHXe+LvDLADg@public.gmane.org,  19606-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org
>> Date: Fri, 16 Jan 2015 13:04:00 +0100
>> 
>> (gdb) thread 1
>> [Switching to thread 1 (Thread 17252.0x44f0)]
>> #0  0x01142191 in Fnext_single_property_change (position=position@entry=540,
>>     prop=62947906, object=118795585, limit=limit@entry=1356)
>>     at ../../emacs-24.4/src/textprop.c:1034
>> 1034    ../../emacs-24.4/src/textprop.c: No such file or directory.
>> (gdb) backtrace
>> #0  0x01142191 in Fnext_single_property_change (position=position@entry=540,
>>     prop=62947906, object=118795585, limit=limit@entry=1356)
>>     at ../../emacs-24.4/src/textprop.c:1034
>> #1  0x0102e54f in handle_invisible_prop (it=0x889a14)
>>     at ../../emacs-24.4/src/xdisp.c:4379
>> #2  0x01022e18 in handle_stop (it=it@entry=0x889a14)
>>     at ../../emacs-24.4/src/xdisp.c:3478
>> #3  0x010231e9 in next_element_from_string (it=0x889a14)
>>     at ../../emacs-24.4/src/xdisp.c:7915
>> #4  0x01025e1c in get_next_display_element (it=it@entry=0x889a14)
>>     at ../../emacs-24.4/src/xdisp.c:6925
>> #5  0x0102b00f in display_line (it=<optimized out>)
>>     at ../../emacs-24.4/src/xdisp.c:20183
>> #6  0x00000000 in ?? ()
>
> Looks like an infloop due to display or overlay strings with text
> properties.  Can you reproduce this in an unoptimized build?

Here it is (with GNU Emacs 25.0.50.1 (i686-pc-mingw32) of 2015-01-28 on
LEG570):

--8<---------------cut here---------------start------------->8---
$ gdb -p 8340
GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
/cygdrive/d/Users/fni/.gdbinit:19: Error in sourced command file:
No symbol table is loaded.  Use the "file" command.
Attaching to process 8340
[New Thread 8340.0x2568]
[New Thread 8340.0x32f0]
[New Thread 8340.0x1b00]
[New Thread 8340.0x2860]
[New Thread 8340.0x2244]
[New Thread 8340.0xfdc]
[New Thread 8340.0x2d04]
[New Thread 8340.0x2288]
[New Thread 8340.0x4fc]
[New Thread 8340.0x29a8]
[New Thread 8340.0x1980]
[New Thread 8340.0x3b68]
[New Thread 8340.0x1030]
[New Thread 8340.0x36b0]
Reading symbols from /cygdrive/c/Program Files (x86)/emacs-trunk/bin/emacs.exe...done.
0x7758f925 in ntdll!DbgBreakPoint () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb) thread 1
[Switching to thread 1 (Thread 8340.0x2568)]
#0  0x01101915 in XSTRING (a=168379948) at C:/emacs/repo/src/lisp.h:974
(gdb) 974       C:/emacs/repo/src/lisp.h: No such file or directory.
backtrace
#0  0x01101915 in XSTRING (a=168379948) at C:/emacs/repo/src/lisp.h:974
#1  0x01103beb in set_string_intervals (s=168379948, i=0xe3f8b54) at C:/emacs/repo/src/lisp.h:3419
#2  0x01200220 in balance_possible_root_interval (interval=0xe3f8b54) at C:/emacs/repo/src/intervals.c:492
#3  0x01200726 in find_interval (tree=0xe3f8b54, position=135) at C:/emacs/repo/src/intervals.c:676
#4  0x01205d13 in validate_interval_range (object=168379948, begin=0x88b320, end=0x88b320, force=false) at C:/emacs/repo/src/textprop.c:194
#5  0x0120881d in Fnext_single_property_change (position=542, prop=18880, object=168379948, limit=1358) at C:/emacs/repo/src/textprop.c:1029
#6  0x01031bdf in handle_invisible_prop (it=0x88c0b0) at C:/emacs/repo/src/xdisp.c:4280
#7  0x0102fa80 in handle_stop (it=0x88c0b0) at C:/emacs/repo/src/xdisp.c:3377
#8  0x0103b998 in next_element_from_string (it=0x88c0b0) at C:/emacs/repo/src/xdisp.c:7803
#9  0x01039412 in get_next_display_element (it=0x88c0b0) at C:/emacs/repo/src/xdisp.c:6835
#10 0x01063121 in display_line (it=0x88c0b0) at C:/emacs/repo/src/xdisp.c:20151
#11 0x01057332 in try_window (window=24604037, pos=..., flags=1) at C:/emacs/repo/src/xdisp.c:16911
#12 0x010540b3 in redisplay_window (window=24604037, just_this_one_p=true) at C:/emacs/repo/src/xdisp.c:16384
#13 0x0104c66b in redisplay_window_1 (window=24604037) at C:/emacs/repo/src/xdisp.c:14216
#14 0x0119e4c4 in internal_condition_case_1 (bfun=0x104c635 <redisplay_window_1>, arg=24604037, handlers=22582667, hfun=0x104c5c3 <redisplay_window_error>) at C:/emacs/repo/src/eval.c:1359
#15 0x0104b9c8 in redisplay_internal () at C:/emacs/repo/src/xdisp.c:13859
#16 0x0104bfb1 in redisplay_preserve_echo_area (from_where=2) at C:/emacs/repo/src/xdisp.c:14045
#17 0x0100faf8 in Fredisplay (force=0) at C:/emacs/repo/src/dispnew.c:5796
#18 0x011a18ba in Ffuncall (nargs=1, args=0x88edd0) at C:/emacs/repo/src/eval.c:2705
#19 0x011e55cf in exec_byte_code (bytestr=19592252, vector=19592269, maxdepth=30, args_template=3078, nargs=1, args=0x88f0fc) at C:/emacs/repo/src/bytecode.c:919
#20 0x011a21b2 in funcall_lambda (fun=19592229, nargs=1, arg_vector=0x88f0f8) at C:/emacs/repo/src/eval.c:2872
#21 0x011a1b4d in Ffuncall (nargs=2, args=0x88f0f4) at C:/emacs/repo/src/eval.c:2754
#22 0x011e55cf in exec_byte_code (bytestr=158475268, vector=165805669, maxdepth=10, args_template=0, nargs=0, args=0x0) at C:/emacs/repo/src/bytecode.c:919
#23 0x011a25dd in funcall_lambda (fun=165805749, nargs=0, arg_vector=0x9e1fe65) at C:/emacs/repo/src/eval.c:2938
#24 0x011a1b4d in Ffuncall (nargs=1, args=0x88f414) at C:/emacs/repo/src/eval.c:2754
#25 0x011e55cf in exec_byte_code (bytestr=158488652, vector=165806149, maxdepth=18, args_template=0, nargs=0, args=0x0) at C:/emacs/repo/src/bytecode.c:919
#26 0x011a25dd in funcall_lambda (fun=165806269, nargs=0, arg_vector=0x9e20045) at C:/emacs/repo/src/eval.c:2938
#27 0x011a1b4d in Ffuncall (nargs=1, args=0x88f750) at C:/emacs/repo/src/eval.c:2754
#28 0x011a1389 in call0 (fn=161383744) at C:/emacs/repo/src/eval.c:2552
#29 0x0110bde6 in safe_run_hooks_1 (nargs=2, args=0x88f7c8) at C:/emacs/repo/src/keyboard.c:1834
#30 0x0119e712 in internal_condition_case_n (bfun=0x110bda1 <safe_run_hooks_1>, nargs=2, args=0x88f7c8, handlers=30496, hfun=0x110bde8 <safe_run_hooks_error>) at C:/emacs/repo/src/eval.c:1417
#31 0x0110c1af in safe_run_hook_funcall (nargs=2, args=0x88f864) at C:/emacs/repo/src/keyboard.c:1882
#32 0x011a1269 in run_hook_with_args (nargs=2, args=0x88f864, funcall=0x110c136 <safe_run_hook_funcall>) at C:/emacs/repo/src/eval.c:2516
#33 0x0110c219 in safe_run_hooks (hook=25408) at C:/emacs/repo/src/keyboard.c:1900
#34 0x0110ad73 in command_loop_1 () at C:/emacs/repo/src/keyboard.c:1535
#35 0x0119e3ab in internal_condition_case (bfun=0x110a4eb <command_loop_1>, handlers=12064, hfun=0x1109be5 <cmd_error>) at C:/emacs/repo/src/eval.c:1335
#36 0x0110a126 in command_loop_2 (ignore=0) at C:/emacs/repo/src/keyboard.c:1139
#37 0x0119d8e6 in internal_catch (tag=31584, func=0x110a0fb <command_loop_2>, arg=0) at C:/emacs/repo/src/eval.c:1095
#38 0x0110a0c5 in command_loop () at C:/emacs/repo/src/keyboard.c:1118
#39 0x01109745 in recursive_edit_1 () at C:/emacs/repo/src/keyboard.c:728
#40 0x01109937 in Frecursive_edit () at C:/emacs/repo/src/keyboard.c:799
#41 0x011078a1 in main (argc=1, argv=0xc515a0) at C:/emacs/repo/src/emacs.c:1607
(gdb)
--8<---------------cut here---------------end--------------->8---

Is that what you need?

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Eli Zaretskii]

> From: Fabrice Niessen <fni-news@pirilampo.org>
> Cc: dgutov@yandex.ru,  19606@debbugs.gnu.org
> Date: Fri, 30 Jan 2015 17:07:13 +0100
> 
> (gdb) thread 1
> [Switching to thread 1 (Thread 8340.0x2568)]
> #0  0x01101915 in XSTRING (a=168379948) at C:/emacs/repo/src/lisp.h:974
> (gdb) 974       C:/emacs/repo/src/lisp.h: No such file or directory.
> backtrace
> #0  0x01101915 in XSTRING (a=168379948) at C:/emacs/repo/src/lisp.h:974
> #1  0x01103beb in set_string_intervals (s=168379948, i=0xe3f8b54) at C:/emacs/repo/src/lisp.h:3419
> #2  0x01200220 in balance_possible_root_interval (interval=0xe3f8b54) at C:/emacs/repo/src/intervals.c:492
> #3  0x01200726 in find_interval (tree=0xe3f8b54, position=135) at C:/emacs/repo/src/intervals.c:676
> #4  0x01205d13 in validate_interval_range (object=168379948, begin=0x88b320, end=0x88b320, force=false) at C:/emacs/repo/src/textprop.c:194
> #5  0x0120881d in Fnext_single_property_change (position=542, prop=18880, object=168379948, limit=1358) at C:/emacs/repo/src/textprop.c:1029
> #6  0x01031bdf in handle_invisible_prop (it=0x88c0b0) at C:/emacs/repo/src/xdisp.c:4280
> #7  0x0102fa80 in handle_stop (it=0x88c0b0) at C:/emacs/repo/src/xdisp.c:3377
> #8  0x0103b998 in next_element_from_string (it=0x88c0b0) at C:/emacs/repo/src/xdisp.c:7803
> #9  0x01039412 in get_next_display_element (it=0x88c0b0) at C:/emacs/repo/src/xdisp.c:6835
> #10 0x01063121 in display_line (it=0x88c0b0) at C:/emacs/repo/src/xdisp.c:20151
> #11 0x01057332 in try_window (window=24604037, pos=..., flags=1) at C:/emacs/repo/src/xdisp.c:16911
> #12 0x010540b3 in redisplay_window (window=24604037, just_this_one_p=true) at C:/emacs/repo/src/xdisp.c:16384
> #13 0x0104c66b in redisplay_window_1 (window=24604037) at C:/emacs/repo/src/xdisp.c:14216
> #14 0x0119e4c4 in internal_condition_case_1 (bfun=0x104c635 <redisplay_window_1>, arg=24604037, handlers=22582667, hfun=0x104c5c3 <redisplay_window_error>) at C:/emacs/repo/src/eval.c:1359
> #15 0x0104b9c8 in redisplay_internal () at C:/emacs/repo/src/xdisp.c:13859
> #16 0x0104bfb1 in redisplay_preserve_echo_area (from_where=2) at C:/emacs/repo/src/xdisp.c:14045
> #17 0x0100faf8 in Fredisplay (force=0) at C:/emacs/repo/src/dispnew.c:5796
> #18 0x011a18ba in Ffuncall (nargs=1, args=0x88edd0) at C:/emacs/repo/src/eval.c:2705
> #19 0x011e55cf in exec_byte_code (bytestr=19592252, vector=19592269, maxdepth=30, args_template=3078, nargs=1, args=0x88f0fc) at C:/emacs/repo/src/bytecode.c:919
> #20 0x011a21b2 in funcall_lambda (fun=19592229, nargs=1, arg_vector=0x88f0f8) at C:/emacs/repo/src/eval.c:2872
> #21 0x011a1b4d in Ffuncall (nargs=2, args=0x88f0f4) at C:/emacs/repo/src/eval.c:2754
> #22 0x011e55cf in exec_byte_code (bytestr=158475268, vector=165805669, maxdepth=10, args_template=0, nargs=0, args=0x0) at C:/emacs/repo/src/bytecode.c:919
> #23 0x011a25dd in funcall_lambda (fun=165805749, nargs=0, arg_vector=0x9e1fe65) at C:/emacs/repo/src/eval.c:2938
> #24 0x011a1b4d in Ffuncall (nargs=1, args=0x88f414) at C:/emacs/repo/src/eval.c:2754
> #25 0x011e55cf in exec_byte_code (bytestr=158488652, vector=165806149, maxdepth=18, args_template=0, nargs=0, args=0x0) at C:/emacs/repo/src/bytecode.c:919
> #26 0x011a25dd in funcall_lambda (fun=165806269, nargs=0, arg_vector=0x9e20045) at C:/emacs/repo/src/eval.c:2938
> #27 0x011a1b4d in Ffuncall (nargs=1, args=0x88f750) at C:/emacs/repo/src/eval.c:2754
> #28 0x011a1389 in call0 (fn=161383744) at C:/emacs/repo/src/eval.c:2552
> #29 0x0110bde6 in safe_run_hooks_1 (nargs=2, args=0x88f7c8) at C:/emacs/repo/src/keyboard.c:1834
> #30 0x0119e712 in internal_condition_case_n (bfun=0x110bda1 <safe_run_hooks_1>, nargs=2, args=0x88f7c8, handlers=30496, hfun=0x110bde8 <safe_run_hooks_error>) at C:/emacs/repo/src/eval.c:1417
> #31 0x0110c1af in safe_run_hook_funcall (nargs=2, args=0x88f864) at C:/emacs/repo/src/keyboard.c:1882
> #32 0x011a1269 in run_hook_with_args (nargs=2, args=0x88f864, funcall=0x110c136 <safe_run_hook_funcall>) at C:/emacs/repo/src/eval.c:2516
> #33 0x0110c219 in safe_run_hooks (hook=25408) at C:/emacs/repo/src/keyboard.c:1900
> #34 0x0110ad73 in command_loop_1 () at C:/emacs/repo/src/keyboard.c:1535
> #35 0x0119e3ab in internal_condition_case (bfun=0x110a4eb <command_loop_1>, handlers=12064, hfun=0x1109be5 <cmd_error>) at C:/emacs/repo/src/eval.c:1335
> #36 0x0110a126 in command_loop_2 (ignore=0) at C:/emacs/repo/src/keyboard.c:1139
> #37 0x0119d8e6 in internal_catch (tag=31584, func=0x110a0fb <command_loop_2>, arg=0) at C:/emacs/repo/src/eval.c:1095
> #38 0x0110a0c5 in command_loop () at C:/emacs/repo/src/keyboard.c:1118
> #39 0x01109745 in recursive_edit_1 () at C:/emacs/repo/src/keyboard.c:728
> #40 0x01109937 in Frecursive_edit () at C:/emacs/repo/src/keyboard.c:799
> #41 0x011078a1 in main (argc=1, argv=0xc515a0) at C:/emacs/repo/src/emacs.c:1607
> (gdb)
> --8<---------------cut here---------------end--------------->8---
> 
> Is that what you need?

Yes, thanks.  Unfortunately, it doesn't say more than the previous
backtrace: Emacs is displaying some display string with invisible
property.  Why that would lead to an infloop, I don't see.

My suggestion at this point would be to ask on the Org list whether
your Org-related setup that triggers this (somehow related to flyspell
mode) might be the problem.  It could be that the infloop is actually
on the Lisp level in some code that is part of Org or your
customizations.

Failing that, I suggest to try to present a minimal reproduction
recipe and post it here.

Thanks.

bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Glenn Morris]

Eli Zaretskii wrote:

> Yes, thanks.  Unfortunately, it doesn't say more than the previous
> backtrace: Emacs is displaying some display string with invisible
> property.  Why that would lead to an infloop, I don't see.
>
> My suggestion at this point would be to ask on the Org list whether
> your Org-related setup that triggers this (somehow related to flyspell
> mode) might be the problem.  It could be that the infloop is actually
> on the Lisp level in some code that is part of Org or your
> customizations.
>
> Failing that, I suggest to try to present a minimal reproduction
> recipe and post it here.

Closing after 2 years with no further progress.