Emacs hangs with 100pc CPU during query-replace

Emacs hangs with 100pc CPU during query-replace

[Thorsten Jolitz]

Hi List, 

I cannot reproduce it with emacs -Q nor give a MWE (unfortunately), but
it happened several times now:

when trying to query replace the name of an Org-mode headline property
in a small Org file Emacs hangs with 100pc CPU after just typing SPACE
(accept) a few times and I get something like this when trying to
interrupt:

,----
| [tj@arch ~]$ fg
| em
| Auto-save? (y or n) y
| Auto-save done
| Abort (and dump core)? (y or n) y
| Fatal error 6: Aborted
| Backtrace:
| emacs[0x4fae93]
| emacs[0x4e094e]
| emacs[0x4faed3]
| emacs[0x4e353e]
| emacs[0x4faabd]
| /usr/lib/libpthread.so.0(+0xf4b0)[0x7f4079de14b0]
| emacs[0x5585f6]
| emacs[0x55ab32]
| emacs[0x554025]
| emacs[0x5899db]
| emacs[0x553b7f]
`----

maybe this info is useful for somebody ...

PS

GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2)
 of 2014-06-11 on var-lib-archbuild-staging-x86_64-jgc

-- 
cheers,
Thorsten

Re: Emacs hangs with 100pc CPU during query-replace

[Michael Heerdegen]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> | Backtrace:
> | emacs[0x4fae93]
> | emacs[0x4e094e]
> | emacs[0x4faed3]
> | emacs[0x4e353e]
> | emacs[0x4faabd]
> | /usr/lib/libpthread.so.0(+0xf4b0)[0x7f4079de14b0]
> | emacs[0x5585f6]
> | emacs[0x55ab32]
> | emacs[0x554025]
> | emacs[0x5899db]
> | emacs[0x553b7f]
> `----

Try sending the Emacs process a SIGUSR2, this forces it into the
(Lisp level) debugger.  Maybe you then can see what it "does".

Re: Emacs hangs with 100pc CPU during query-replace

[Emanuel Berg]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Try sending the Emacs process a SIGUSR2, this forces
> it into the (Lisp level) debugger.  Maybe you then
> can see what it "does".

You mean like this:

kill -s usr2 4352

(get the PID with 'ps -e | grep emacs')

or, equivalently (?)

pkill --signal usr2 emacs

That doesn't do a lot for me. It only says "Quit" in
the echo area. But perhaps that is the debugger
quiting, not finding anything to debug?

-- 
underground experts united

Re: Emacs hangs with 100pc CPU during query-replace

[Michael Heerdegen]

Emanuel Berg <embe8573@student.uu.se> writes:

> You mean like this:
>
> kill -s usr2 4352
>
> (get the PID with 'ps -e | grep emacs')
>
> or, equivalently (?)
>
> pkill --signal usr2 emacs

Exactly.

> That doesn't do a lot for me. It only says "Quit" in the echo
> area. But perhaps that is the debugger quiting, not finding anything
> to debug?

Too bad.  I do get a debugger all the time, even if Emacs is completely
idle.  Maybe your Emacs is even too busy to get the debugger up.

AFAIK the "QUIT" message you get doesn't mean that the debugger has
quit.  Sending usr2 causes the `debug-on-quit' flag to be set and
additionally causes a quit signal.  In combination, this causes the
debugger to be entered.

Re: Emacs hangs with 100pc CPU during query-replace

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Too bad.  I do get a debugger all the time, even if Emacs is completely
> idle.  Maybe your Emacs is even too busy to get the debugger up.

Sorry, I see now that it wasn't you that had the problem.

If you "let Emacs do something" you really should get a debugger with
SIGUSR2.  E.g. try just to type M-: or M-x and leave the minibuffer open.

Re: Emacs hangs with 100pc CPU during query-replace

[Emanuel Berg]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> AFAIK the "QUIT" message you get doesn't mean that
> the debugger has quit.  Sending usr2 causes the
> debug-on-quit' flag to be set and additionally causes
> a quit signal.  In combination, this causes the
> debugger to be entered.

OK! So it boils down to:

(setq debug-on-quit t)
(signal 'quit nil)

That messages Quit, but nothing more what I can see.

-- 
underground experts united

Re: Emacs hangs with 100pc CPU during query-replace

[Emanuel Berg]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> If you "let Emacs do something" you really should get
> a debugger with SIGUSR2.  E.g. try just to type M-:
> or M-x and leave the minibuffer open.

For me, it is the same there. But turns out, it is a
configuration problem. With 'emacs -Q', it works as you
say.

-- 
underground experts united

if and only if an Error message (was: Re: Emacs hangs with 100pc CPU during query-replace)

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

>> If you "let Emacs do something" you really should
>> get a debugger with SIGUSR2.  E.g. try just to type
>> M-: or M-x and leave the minibuffer open.
>
> For me, it is the same there. But turns out, it is a
> configuration problem. With 'emacs -Q', it works as
> you say.

OK, that wasn't it, either.

The _first_ time I do it, namely

(progn
  (setq debug-on-quit t)
  (signal 'quit nil) )

it brings up the *Backtrace* buffer. Second time and
forever after, it is just "Quit" in the echo area. The
same actually for any error: for example,

(message 'not-a-string)

- first time the buffer, thereafter a message saying:

    eval: Wrong type argument: stringp, not-a-string

So the error doesn't have to be the same. Only the
first gets the backtrace. Even with `M-x debug' (which
shows the backtrace buffer), the new error(s) doesn't
seem to be documented there.

Isn't there like an *Errors* buffer were only error
messages gets stored, and all of them?

-- 
underground experts united

Re: if and only if an Error message

[Michael Heerdegen]

Hi,

did you quit the debugger the first time and return to the toplevel?  If
not, then what you see is expected - a new debugging session is not
started when a session is already active, because that would be annoying
while debugging.

Re: if and only if an Error message

[Emanuel Berg]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> did you quit the debugger the first time and return
> to the toplevel?  If not, then what you see is
> expected - a new debugging session is not started
> when a session is already active, because that would
> be annoying while debugging.

I did close the backtrace buffer. I can bring it back
with `debug' but it doesn't report the new errors, and
old stuff still there.

Do you know how to just have all error messages in a
separate buffer, and never bring up the debugger unless
I say so?

-- 
underground experts united

Re: if and only if an Error message

[Michael Heerdegen]

Emanuel Berg <embe8573@student.uu.se> writes:

> > did you quit the debugger the first time and return
> > to the toplevel?  If not, then what you see is
> > expected - a new debugging session is not started
> > when a session is already active, because that would
> > be annoying while debugging.
>
> I did close the backtrace buffer. I can bring it back
> with `debug' but it doesn't report the new errors, and
> old stuff still there.

It doesn't suffice to close the window, you must quit the debugger with
q.  Even killing the debugger buffer doesn't bring you back to the
top-level.

> Do you know how to just have all error messages in a
> separate buffer, and never bring up the debugger unless
> I say so?

Like (setq debug-on-error nil)?  But this doesn't use a separate buffer,
it uses *Messages*.

Re: if and only if an Error message

[Emanuel Berg]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> It doesn't suffice to close the window, you must quit
> the debugger with q.  Even killing the debugger
> buffer doesn't bring you back to the top-level.

OK!

>> Do you know how to just have all error messages in a
>> separate buffer, and never bring up the debugger
>> unless I say so?
>
> Like (setq debug-on-error nil)?  But this doesn't use
> a separate buffer, it uses *Messages*.

OK, I just found another variable, inhibit-debugger,
sounds interesting as well...

*Messages* is in fundamental-mode, and there seems to
be no special notation for errors, so they can't be
filtered and/or highlighted that way either...

-- 
underground experts united

Re: if and only if an Error message

[Michael Heerdegen]

Emanuel Berg <embe8573@student.uu.se> writes:

> OK, I just found another variable, inhibit-debugger,
> sounds interesting as well...

But that one is not intended to be set by the user.

> *Messages* is in fundamental-mode, and there seems to be no special
> notation for errors, so they can't be filtered and/or highlighted that
> way either...

Is that really so much useful?  Anyway, you could set
`command-error-function' to do what you want.

Re: if and only if an Error message

[Michael Heerdegen]

Emanuel Berg <embe8573@student.uu.se> writes:

> > It doesn't suffice to close the window, you must quit
> > the debugger with q.  Even killing the debugger
> > buffer doesn't bring you back to the top-level.

BTW, if the debugger session is still active, you see [...] around the
modes displayed in the mode line (one pair for each recursive edit).  Get
back to the top level with M-x top-level.

Re: if and only if an Error message

[Emanuel Berg]

Michael Heerdegen <michael_heerdegen@web.de> writes:

>> OK, I just found another variable, inhibit-debugger,
>> sounds interesting as well...
>
> But that one is not intended to be set by the user.

OK, if that is harmful (?) perhaps it should be
mentioned in the documentation:

    Non-nil means never enter the debugger.  Normally
    set while the debugger is already active, to avoid
    recursive invocations.

>> *Messages* is in fundamental-mode, and there seems
>> to be no special notation for errors, so they can't
>> be filtered and/or highlighted that way either...
>
> Is that really so much useful?  Anyway, you could set
> command-error-function' to do what you want.

OK, will do! Yes, it is useful so I can study the error
messages and see if any of them is something that I'd
care to analyze and/or fix. Now I'm basically unaware
of them (if they even exits).

-- 
underground experts united

Re: if and only if an Error message

[Michael Heerdegen]

Emanuel Berg <embe8573@student.uu.se> writes:


> >> OK, I just found another variable, inhibit-debugger,
> >> sounds interesting as well...
> >
> > But that one is not intended to be set by the user.
>
> OK, if that is harmful (?) perhaps it should be
> mentioned in the documentation:

It's not harmful.  But it's not a user option, so if you set its value,
you should know what you are doing and how the flag is used internally.


> OK, will do! Yes, it is useful so I can study the error
> messages and see if any of them is something that I'd
> care to analyze and/or fix. Now I'm basically unaware
> of them (if they even exits).

I would start trying something like this:

,----------------------------------------------------------------------
| (defun my-log-error (data _ function)
|   (with-current-buffer (get-buffer-create "*Error*")
|     (goto-char (point-max))
|     (insert (format "%s in %s\n" data function))))
| 
| (setq command-error-function
|       (lambda (&rest args)
|         (apply #'command-error-default-function args)
|         (apply #'my-log-error args)))
`----------------------------------------------------------------------

Re: if and only if an Error message

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> (insert (format "%s in %s\n" data function))))
                   ^^    ^^
Oops, "%S", of course.

Re: Emacs hangs with 100pc CPU during query-replace

[Thorsten Jolitz]

Emanuel Berg <embe8573@student.uu.se> writes:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>> Try sending the Emacs process a SIGUSR2, this forces
>> it into the (Lisp level) debugger.  Maybe you then
>> can see what it "does".
>
> You mean like this:
>
> kill -s usr2 4352
>
> (get the PID with 'ps -e | grep emacs')
>
> or, equivalently (?)
>
> pkill --signal usr2 emacs

nice tip, thanks, I hope I remember this!

Here is the beginning of the file where I want to replace :resource_id:
with :name: by doing 

,----
| M-%: resource_id RET name RET
`----

Emacs hangs already at the 2nd (piano) entry. 

#+begin_src org
* Instruments
** rhythm-section
*** harmony
**** guitar
   :PROPERTIES:
   :name: guitar
   :abbrev:   g
   :END:

**** piano
    :PROPERTIES:
    :name: piano
    :abbrev:   p
    :END:

*** rhythm
**** bass
    :PROPERTIES:
    :resource_id: bass
    :abbrev:   b
    :END:

**** drums
    :PROPERTIES:
    :resource_id: drums
    :abbrev:   dr
    :END:

** horns
    :PROPERTIES:
    :resource_id: horns
    :abbrev:   hrs
    :END:
#+end_src

here is the backtrace I get, it seems to be an Org-mode (cache?) problem
- should I move this report to the Org mailing list?

Debugger entered--Lisp error: (quit)
  looking-at("^\\(\\*+\\)\\(?: +\\(TODO\\|NEXT\\|DONE\\|WAITING\\|HOLD\\|CANCELLED\\|PHONE\\)\\)?\\(?: +\\(\\[#.\\]\\)\\)?\\(?: +\\(.*?\\)\\)??\\(?:[ 	]+\\(:[[:alnum:]_@#%:]+:\\)\\)?[ 	]*$")
  org-heading-components()
  org-element-headline-parser(116 t)
  org-element--current-element(116 element nil nil)
  byte-code("\212\214~\210^Hb\210	\205..\306\307!\204..\n\205..\310^H\311\".\312^K..\f;\203+.\313\314.\f#\2021.\315\fA@.\"*..\311\211../^K\204`.\316.0\317 \211.1.2\320.1P.3\321 ,\203V.\311y\210\322\311w\210\323 \210\202?.^H..U\203\217.\324\325.4\203\211.\326^K..\f;\203^?.\313\314.\f#\202\205.\315\fA@.\"*\202\212.^K\"\210\202?.\327\316.0\317 \211.1.2\320.1P+..\316#\203\263.\311y\210\322\311w\210\323 \210\202?.^Kd^HU\203\277.^HS\202\300.^H..5\330^K..\f;\203\324.\313\314.\f#\202\332.\315\fA@.\"*\206\340...b\210\331.5..\f;\203\364.\313\314.\f#\202\372.\315\fA@.\"*\211.6^HX\205%..6b\205%.\326.5..\f;\203..\313\314.\f#\202!.\315\fA@.\"*\211.5)\204\342..5\203>.m\2038..5.\202>..5.`./*\331\f..\f;\203P.\313\314.\f#\202V.\315\fA@.\"*\206q.\212\316.0\317 \211.1.2\320.1P.3\332 \210,`)\f\311.7.8.6.4\203\251.`^HU\203\215.\324\325.8\"\210\202\251..9\211.9\205\240.\333 \206\240.\334.9\335 \")\203\251.\324\336\311\"\210\f\204\370.\337.6\304.7\340.8..\f;\203\305.\313\314.\f#\202\313.\315\fA@.\"*$\211.\326.8.:.\211.;\203\345.\341\f\311..:$\202\362.\fA\342\fA@..:#\240\210\f+\210\343\f!\210\331\f..\f;\203	.\313\314.\f#\202..\315\fA@.\"*\f\211.:\204 .\f;\205(.\344\202(.\f@9\205(.\f@).;\211.<^HX\203A.d.<U\204A..<b\210\202\376..;.=>\204Q.\324\325\f\"\210\202\376.\330\f..\f;\203b.\313\314.\f#\202h.\315\fA@.\"*\345\f..\f;\203z.\313\314.\f#\202\200.\315\fA@.\"*.>.?.4\204\276..?\205\365..>\205\365..?^HW\204\252..?^HU\205\365..;\346>?\205\365..>^HV\204\276..>^HU\205\365.d^HU\205\365../\206\305..?b\210\311./\347.;\350\"\203\326.\351\202\353.\347.;\352\"\203\342.\353\202\353.\347.;\354\"\205\353.\355.7\f.8.>\211.6*\204\376.\324\325\f\"\210*\311.\202y." [pos org-element-use-cache orgstruct-mode cached element property derived-mode-p org-mode org-element--cache-find nil :begin get-text-property 0 plist-get t org-get-limited-outline-regexp "^" outline-previous-heading " .	\n" beginning-of-line throw exit :parent re-search-backward :contents-begin :end outline-next-heading input-pending-p time-less-p current-time interrupt org-element--current-element :structure org-add-props plist-put org-element--cache-put plain-text :contents-end (plain-list table) eql plain-list item property-drawer node-property table table-row begin next org-called-with-limited-levels org-outline-regexp ...] 9)
  org-element--parse-to(120 t nil)
  byte-code("^H\306H\307U\203\f.\310\311\215\210^H\306H\312U\203U.^H\307H	\232\203(.\nA@\306\312I\210\313\314\315\"\210\316^H\312H^H\317H^K#..\203A..\fW\203A.\313\320\321\"\210\322\f\315..#./^H\323./I\210^H\306\324I\210*^H\307H^H\317H^H\323H.0\307H.1>\204n.\325\326\327\330#\210.0\312H\307H\321C\315\321.2.3.4.5./.6.7./\204\227.\331.6!\203\227.\313\314\315\"\210.5\203\251..5\324H\211.8.9\332.9.:\"\206..\333.9.9.;.9;\203\305.\334\307.;.9#\202\315.\335.9A@.;\"*.<.9\211.9:\204\343..9;\205\355.\336\202\355..9@9\205\355..9@)\337>\203\371..<T\202\373..<.=\n\203\f.\340.9.=.:#\202...=*).=.3\203h..5\307H\203h..=.7.>\211.?\250\203B..>\250\2039..?.>W\202T..?.>@X\202T..>\250\203Q..?@.>W\202T.\341\342\215*\204h..5.4B.4.5\307H.5\202\245..=.7.>\211.?\250\203\214..>\250\203\203..?.>W\202\236..?.>@X\202\236..>\250\203\233..?@.>W\202\236.\341\342\215*\204\213..=	\232\203\256.\313\314\315\"\210.2\204\312...\211..\205\306.\343 \206\306.\344..\345 \")\203\333.^H\307.=I\210^H\323./I\210\313\320\321\"\210\331.6!\204\334..8.6\321.@.6\211.9A@.A.@\203\376.\346.@>\203\x7f..9\211.9:\204...9;\205..\336\202...9@9\205...9@)\347=\203\x7f.\335.A\350\"\211.9:\2047..9;\205A.\336\202A..9@9\205A..9@)\351=\204\x7f.\335.A\346\"\321.)\211.B\203~..B@\211.)\211.C\211@.6\\\240\210)\306.)\233\211.D\211@.6\\\240\210).BA\211.B\204U.*\352\321.=\211.B\205\276..B@.=.@\203\233..=.@>\205\241.\335.A.=\"\211.E\203\263.\353.A.=.6.E\\#\210).BA\211.B\204\211.\321..\210\332.8.F\"\321.G\211.B\203\333..B@\211.G\211.HAA)\321.I\211.B\203\321..B@\211.I.6\321.@.6\211.9A@.A.@\203..\346.@>\203\206..9\211.9:\204...9;\205\".\336\202\"..9@9\205\"..9@)\347=\203\206.\335.A\350\"\211.9:\204>..9;\205H.\336\202H..9@9\205H..9@)\351=\204\206.\335.A\346\"\321.)\211.B\203\205..B@\211.)\211.C\211@.6\\\240\210)\306.)\233\211.D\211@.6\\\240\210).BA\211.B\204\\.*\352\321.=\211.B\205\305..B@.=.@\203\242..=.@>\205\250.\335.A.=\"\211.E\203\272.\353.A.=.6.E\\#\210).BA\211.B\204\220.\321..\210.BA\211.B\204\345.*.BA\211.B\204\320.*\333.8.9.;.9;\203\363.\334\307.;.9#\202\373.\335.9A@.;\"*.<./\203O.\354./.9.;.9;\203..\334\307.;.9#\202\".\335.9A@.;\"*.<X\203O.\350./.9.;.9;\203@.\334\307.;.9#\202H.\335.9A@.;\"*\211./\204.../\204c.\331.6!\203c.\313\314\321\"\210\202|../\203|.\350.8.9.;.9;\203\x7f.\334\307.;.9#\202\207.\335.9A@.;\"*\211.J?\206\320.\333.J.9.;.9;\203\246.\334\307.;.9#\202\256.\335.9A@.;\"*\333./.9.;.9;\203\306.\334\307.;.9#\202\316.\335.9A@.;\"*W)\203|..8\350./.E.;\211.9;\203\360.\355.9\321.;.E$\202...9A\353.9A@.;.E#\240\210.9+\210\346./.9.;.9;\203..\334\307.;.9#\202\".\335.9A@.;\"*\211.K\203{.\346.8.9.;.9;\203@.\334\307.;.9#\202H.\335.9A@.;\"*\203{..8\346.K.E.;\211.9;\203h.\355.9\321.;.E$\202y..9A\353.9A@.;.E#\240\210.9+\210).\203\212..<.V\203\212.\315.2).5\312H\211.3\203\234..5\312H\202\243..4\211A.4@.5*\202\227..^G\315\207" [request next org-element--cache-sync-requests extra limit threshold 6 0 end-phase (byte-code "^H\306H^H\307H^H\310H...\f\211.\205..\311 \206..\312\f\313 \")\203%.\314\315\316\"\210.\306H.$>\2044.\317\320\321\322#\210.\323H\306H\316\211.%.&.'.'\203W..'\307H\211.(.(\324.(.)\"\206\272.\325.(.(.*.(;\203o.\326\306.*.(#\202w.\327.(A@.*\"*.+.(\211.(:\204\215..(;\205\227.\330\202\227..(@9\205\227..(@)\331>\203\243..+T\202\245..+.,.-\203\267.\332.(.,.)#\202\271..,*)\211.,^K..\211./\250\203\337...\250\203\326../..W\202\361../..@X\202\361...\250\203\356../@..W\202\361.\333\334\215*\203\376..'\323H.'\202S.^K.,..\211./\250\203!...\250\203.../..W\2023../..@X\2023...\250\2030../@..W\2023.\333\334\215*\203H..(.&.,.%.'\306H.'\202S..(.&.,.%\316.'*\202A..&\203..\325.&.(.*.(;\203s.\326\306.*.(#\202{.\327.(A@.*\"*.0.1\203\275..%.1..\211./\250\203\247...\250\203\236../..W\202\271../..@X\202\271...\250\203\266../@..W\202\271.\333\334\215*\203\304..0\nX\202\374..&\211.2\203\371..2	=\204\371.\335.2.(.*.(;\203\352.\326\306.*.(#\202\362.\327.(A@.*\"*\211.2\204\314..2)\203...&.(\336..(\"\210\337.(.3\")\210\202*.^H\306.%I\210^H\323.0I\210^H\340\323I\210\314\341\316\"\210)\2023.\314\342\343\"\210+\202\f." [request outreach end beg time-limit org-element--cache 0 2 4 input-pending-p time-less-p current-time throw interrupt nil error "%s accessing a non-%s" avl-tree--dummyroot avl-tree- 1 gethash :begin get-text-property plist-get plain-text (item table-row) puthash exit (byte-code "^H\203/.	\203/.\302^H	\"\203..\303\304\305\"\210\202..\302	^H\"\203&.\303\304\306\"\210\202..^HA.	A.\202..^H?\2055.	\207" [a b car-less-than-car throw exit t nil] 3) :parent avl-tree-delete remhash 6 end-phase quit t cl-struct-avl-tree--tags data-key data node element org-element--cache-sync-keys property begin key org-element--cache-sync-requests b a pos next ...] 5) 1 throw quit t + 3 interrupt nil org-element--parse-to 5 2 error "%s accessing a non-%s" avl-tree--dummyroot avl-tree- zerop gethash :begin get-text-property plist-get plain-text (item table-row) puthash exit (byte-code "^H\203/.	\203/.\302^H	\"\203..\303\304\305\"\210\202..\302	^H\"\203&.\303\304\306\"\210\202..^HA.	A.\202..^H?\2055.	\207" [a b car-less-than-car throw exit t nil] 3) input-pending-p time-less-p current-time :structure plain-list :parent item (:begin :contents-begin :contents-end :end :post-affiliated) plist-put :end org-add-props time-limit parent org-element--cache cl-struct-avl-tree--tags ...] 8)
  org-element--cache-process-request([1642 134 123 -7 (property-drawer (:begin 57 :end 123 :contents-begin 73 :contents-end 113 :post-blank 1 :post-affiliated 57 :parent nil)) nil 2] nil 167 nil -7)
  byte-code("^H\203H.^H@.^HA@.\306	\n\205..\n\307H^K\211?\205^_.\310\311 \f\".\206$.\307%\210\n\203A.\n\211.\f\312.\f\312H	\312H\\I\210)\n\313	\313HI\210^HA\211.\204..\306\207" [org-element--cache-sync-requests request next threshold org-element-cache-sync-duration extra org-element--cache-process-request 0 time-add current-time 3 2 v] 8)
  org-element--cache-sync(#<buffer instruments.org> 167 -7)
  org-element--cache-submit-request(144 167 -7)
  org-element--cache-after-change(149 153 11)
  replace-match("name" nil t)
  replace-match-maybe-edit("name" nil t nil (149 160 #<buffer instruments.org>))
  perform-replace("resource_id" "name" t nil nil nil nil nil nil)
  query-replace("resource_id" "name" nil nil nil)
  call-interactively(query-replace nil nil)

-- 
cheers,
Thorsten

Re: Emacs hangs with 100pc CPU during query-replace

[Eli Zaretskii]

> From: Thorsten Jolitz <tjolitz@gmail.com>
> Date: Sat, 19 Jul 2014 10:02:02 +0200
> 
> here is the backtrace I get, it seems to be an Org-mode (cache?) problem

Indeed.

> - should I move this report to the Org mailing list?

Yes, please.

Re: Emacs hangs with 100pc CPU during query-replace

[Michael Heerdegen]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> here is the backtrace I get, it seems to be an Org-mode (cache?) problem
> - should I move this report to the Org mailing list?

You should really try to find a reproducible recipe - try bisecting your
configuration.  Some org list is probably the best place to discuss
this issue, yes.  It looks like a bug.

I can't reproduce it.  My org version doesn't even seem to have any of
these `org-element--cache...' functions appearing in your backtrace.  Do
you use a development version of org?

Re: Emacs hangs with 100pc CPU during query-replace

[Thorsten Jolitz]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> here is the backtrace I get, it seems to be an Org-mode (cache?) problem
>> - should I move this report to the Org mailing list?
>
> You should really try to find a reproducible recipe - try bisecting your
> configuration.  Some org list is probably the best place to discuss
> this issue, yes.  It looks like a bug.

I already sent a copy to the Org list. Seems there are a few
org-element--cache related problems right now.

> I can't reproduce it.  My org version doesn't even seem to have any of
> these `org-element--cache...' functions appearing in your backtrace.  Do
> you use a development version of org?

Yes, I use the git version and made a "make update" just last night.

-- 
cheers,
Thorsten

Re: Emacs hangs with 100pc CPU during query-replace

[Thorsten Jolitz]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> here is the backtrace I get, it seems to be an Org-mode (cache?) problem
>> - should I move this report to the Org mailing list?
>
> You should really try to find a reproducible recipe - try bisecting your
> configuration.  

Now I could reproduce it with emacs -Q, it just don't happens at the
same headline always, this time emacs hanged at the 5th entry. 

Recipe is:

1. emacs -Q

2. M-x find-file instruments.org (content posted below)

3. M-% resource_id RET name RET

4. hit space quickly (-> accept) until Emacs hangs (100pc CPU)

PS 1

One more question: the backtraces I get contain ascii-control characters
- how can I copy/insert them into an email with these chars replaced (by
their string representation -> ^K e.g.)?

PS 2

content of instruments.org:

* Instruments
** rhythm-section
*** harmony
**** guitar
   :PROPERTIES:
   :resource_id: guitar
   :abbrev:   g
   :END:

**** piano
    :PROPERTIES:
    :resource_id: piano
    :abbrev:   p
    :END:

*** rhythm
**** bass
    :PROPERTIES:
    :resource_id: bass
    :abbrev:   b
    :END:

**** drums
    :PROPERTIES:
    :resource_id: drums
    :abbrev:   dr
    :END:

** horns
    :PROPERTIES:
    :resource_id: horns
    :abbrev:   hrs
    :END:

*** brass
**** trumpet
    :PROPERTIES:
    :resource_id: trumpet
    :abbrev:   tr
    :pitch:    +2
    :END:

**** trombone
    :PROPERTIES:
    :resource_id: trombone
    :abbrev:   tmb
    :END:

*** woodwinds
**** sopran-sax
    :PROPERTIES:
    :resource_id: sopran-sax
    :abbrev:   ss
    :END:

**** alt-sax
    :PROPERTIES:
    :resource_id: alt-sax
    :abbrev:   as
    :pitch:    -3
    :END:

**** tenor-sax 
    :PROPERTIES:
    :resource_id: tenor-sax
    :abbrev:   ts
    :pitch:    +2
    :END:

**** bariton-sax
    :PROPERTIES:
    :resource_id: bariton-sax
    :abbrev:   bs
    :END:

**** flute
    :PROPERTIES:
    :resource_id: flute
    :abbrev:   fl
    :END:

*** voices
**** sopran-voice
    :PROPERTIES:
    :resource_id: sopran-voice
    :abbrev:   svoc
    :END:

**** alt-voice
    :PROPERTIES:
    :resource_id: alt-voice
    :abbrev:   avoc
    :END:

**** tenor_voice
    :PROPERTIES:
    :resource_id: tenor-voice
    :abbrev:   tvoc
    :END:

**** bariton-voice
    :PROPERTIES:
    :resource_id: bariton-voice
    :abbrev:   bvoc
    :END:

*** strings
**** violin
    :PROPERTIES:
    :resource_id: violin
    :abbrev:   v
    :END:

**** Cello
    :PROPERTIES:
    :resource_id: cello
    :abbrev:   c
    :END:


-- 
cheers,
Thorsten

Re: Emacs hangs with 100pc CPU during query-replace

[Eli Zaretskii]

> From: Thorsten Jolitz <tjolitz@gmail.com>
> Date: Sat, 19 Jul 2014 11:06:14 +0200
> 
> One more question: the backtraces I get contain ascii-control characters
> - how can I copy/insert them into an email with these chars replaced (by
> their string representation -> ^K e.g.)?

You shouldn't bother, as those characters are not helpful anyway.

If you want to produce a more helpful backtrace, manually load each
library as .el file, then the backtrace will not include byte code.

Re: Emacs hangs with 100pc CPU during query-replace

[Eli Zaretskii]

> From: Thorsten Jolitz <tjolitz@gmail.com>
> Date: Sat, 19 Jul 2014 11:06:14 +0200
> 
> 1. emacs -Q
> 
> 2. M-x find-file instruments.org (content posted below)
> 
> 3. M-% resource_id RET name RET
> 
> 4. hit space quickly (-> accept) until Emacs hangs (100pc CPU)

It doesn't hang with today's trunk and the version of Org in the Emacs
trunk.

So I think you should take this up with the Org developers first.  If
they conclude that there's some core Emacs problem here, I suggest to
file a bug report with a reproducible recipe, preferably using only
the Emacs trunk files.

Re: Emacs hangs with 100pc CPU during query-replace

[Thorsten Jolitz]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thorsten Jolitz <tjolitz@gmail.com>
>> Date: Sat, 19 Jul 2014 11:06:14 +0200
>> 
>> One more question: the backtraces I get contain ascii-control characters
>> - how can I copy/insert them into an email with these chars replaced (by
>> their string representation -> ^K e.g.)?
>
> You shouldn't bother, as those characters are not helpful anyway.
>
> If you want to produce a more helpful backtrace, manually load each
> library as .el file, then the backtrace will not include byte code.

yes, that gives a much better backtrace, thx.

-- 
cheers,
Thorsten

Re: Emacs hangs with 100pc CPU during query-replace

[Thorsten Jolitz]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thorsten Jolitz <tjolitz@gmail.com>
>> Date: Sat, 19 Jul 2014 11:06:14 +0200
>> 
>> 1. emacs -Q
>> 
>> 2. M-x find-file instruments.org (content posted below)
>> 
>> 3. M-% resource_id RET name RET
>> 
>> 4. hit space quickly (-> accept) until Emacs hangs (100pc CPU)
>
> It doesn't hang with today's trunk and the version of Org in the Emacs
> trunk.
>
> So I think you should take this up with the Org developers first.  If
> they conclude that there's some core Emacs problem here, I suggest to
> file a bug report with a reproducible recipe, preferably using only
> the Emacs trunk files.

Done. I think its about org-element cache problems, but I'm just
guessing. 

-- 
cheers,
Thorsten

Re: if and only if an Error message

[Emanuel Berg]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> It's not harmful.  But it's not a user option, so if
> you set its value, you should know what you are doing
> and how the flag is used internally.

If I had to know what I'm doing nothing would ever be
done. Even more so, if I know it, then why do it...

But put it this way: how do I find out a variable isn't
a user option?

> I would start trying something like this ...

Thank you!

Yes, check this out - 

(setq error-buffer-name "*Errors*")

;; inhibit the debugger -
;;   try this if nothing else: a wonderful thing to not
;;   have it hop out over half the screen for something
;;   that can be communicated in a few words
(setq debug-on-error nil)
(setq eval-expression-debug-on-error nil)

;; this does three things, see the comments
(defun say-and-log-error (data _ fun)
  (let*((error-str (format "%S in %S" data fun))
        (error-buffer (get-buffer-create error-buffer-name))
        (error-win (get-buffer-window error-buffer)) )
    (message error-str)                  ; echo the error message
    (with-current-buffer error-buffer
      (goto-char (point-max))
      (insert error-str "\n") )          ; log it
    (if error-win
        (with-selected-window error-win  ; move focus of error window
          (goto-char (point-max))        ; if available
          (recenter -1)) )))             ; (is there a better way?)

;; use it instead of the default one          
(setq command-error-function
      (lambda (&rest args)
        (apply #'say-and-log-error args)) )

;; show the error buffer        
(defun show-errors ()
  (interactive)
  (switch-to-buffer (get-buffer-create error-buffer-name))
  (goto-char (point-max)) ; the same situation: the last line of data
  (recenter -1) )         ; should be on the last window line
                          ; whenever possible

; test here:
; (message 'error-as-not-string)

-- 
underground experts united

RE: Emacs hangs with 100pc CPU during query-replace

[Drew Adams]

> > One more question: the backtraces I get contain ascii-control characters
> > - how can I copy/insert them into an email with these chars replaced (by
> > their string representation -> ^K e.g.)?
> 
> You shouldn't bother, as those characters are not helpful anyway.
> 
> If you want to produce a more helpful backtrace, manually load each
> library as .el file, then the backtrace will not include byte code.

Yes, as Eli says, loading source code provides a more helpful
backtrace (more and better information).  And yes, characters
introduced by byte code are not helpful/useful.

But see Emacs bug #6991:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6991/

This is what jidanni reported in #6991:

  Please keep bytecode out of *Backtrace* buffers.
  * It is unreadable.
  * It will cause problems when sent via email. Even if one runs
    col(1) and strings(1) on it, nobody can read it anyway.
  * The mountain of gobbledygook makes people reading give up on
    trying to help. E.g., http://article.gmane.org/gmane.emacs.w3m/8695

Emacs users should be able to paste a backtrace that does contain
byte-code chars, and have those chars elided or removed, rather
than have the pasted text be truncated at some point because of
a byte-code char.

IOW, users should not need to fiddle with a backtrace to try to
piece together its non byte-code parts when trying to report it.

In addition, it is not very practical to ask users to find and
load each and every source file that might contribute to a backtrace.
Especially if the trace appeared because of `debug-on-error' and it
might not be easy to reproduce the error.

And even if only source code is loaded, there can be some code
parts that are byte-compiled (programmatically).  Byte-compiling
is not limited to a whole file.

No reason was given for not fixing bug #6991, or even for keeping
it open but relegating it to the `wishlist' until someone can get
around to fixing it.  What was the response to jidanni's bug filing?
This one-liner:

  From: Glenn Morris
  No. Closed as wontfix.

That is not very helpful.

With some struggle, we eventually got the `wontfix' tag removed, the
bug moved to `wishlist' and tagged `patch' (Stefan provided a patch
that he says does not work for him).  But other than that, no progress.

RE: if and only if an Error message

[Drew Adams]

> how do I find out a variable isn't a user option?

C-h v

Re: if and only if an Error message

[Michael Heerdegen]

Emanuel Berg <embe8573@student.uu.se> writes:


> But put it this way: how do I find out a variable isn't
> a user option?

Yes, C-h v.  User options are these variables that can be "customized".


> (setq error-buffer-name "*Errors*")
>
> ;; inhibit the debugger -
> ;;   try this if nothing else: a wonderful thing to not
> ;;   have it hop out over half the screen for something
> ;;   that can be communicated in a few words
> (setq debug-on-error nil)
> (setq eval-expression-debug-on-error nil)
>
> ;; this does three things, see the comments
> (defun say-and-log-error (data _ fun)
>   (let*((error-str (format "%S in %S" data fun))
>         (error-buffer (get-buffer-create error-buffer-name))
>         (error-win (get-buffer-window error-buffer)) )
>     (message error-str)                  ; echo the error message
>     (with-current-buffer error-buffer
>       (goto-char (point-max))
>       (insert error-str "\n") )          ; log it
>     (if error-win
>         (with-selected-window error-win  ; move focus of error window
>           (goto-char (point-max))        ; if available
>           (recenter -1)) )))             ; (is there a better way?)
>
> ;; use it instead of the default one          
> (setq command-error-function
>       (lambda (&rest args)
>         (apply #'say-and-log-error args)) )
>
> ;; show the error buffer        
> (defun show-errors ()
>   (interactive)
>   (switch-to-buffer (get-buffer-create error-buffer-name))
>   (goto-char (point-max)) ; the same situation: the last line of data
>   (recenter -1) )         ; should be on the last window line
>                           ; whenever possible
>
> ; test here:
> ; (message 'error-as-not-string)

Looks good.

Maybe also call `discard-input' as `command-error-default-function'
does.

And (message "%s" error-str).
             ^^^^

Have fun,

Michael.

Re: if and only if an Error message

[Emanuel Berg]

Michael Heerdegen <michael_heerdegen@web.de> writes:

>> But put it this way: how do I find out a variable
>> isn't a user option?
>
> Yes, C-h v.  User options are these variables that
> can be "customized".

:)

That was a subtle way of communicating that! OK, I take
back my complaints about the docstring...

> Maybe also call `discard-input' as
> `command-error-default-function' does.

Well, yes, I removed that part from your suggestion
(not `discard-input' but the whole part with
`command-error-default-function') because I don't have
that, neither as a function or a variable. Do you have
it? What is it?

> And (message "%s" error-str).
>              ^^^^

Isn't it already a string from this?

(let*((error-str (format "%S in %S" data fun))

-- 
underground experts united

avoiding global variables (was: Re: if and only if an Error message)

[Emanuel Berg]

I thought perhaps the new insights on dynamic and
lexical scope could help me with a problem I've had a
couple of times. I think the reason I never had any
problems with dynamic vs. lexical is the way I almost
exclusively used identifiers that were either of `let's
or function parameters. But I came to think of one case
that wasn't so, and an example of that I posted in the
thread on the debugger (code last). Here, is there any
way to not make `error-buffer-name' global but to
associate it exclusively with the two defuns that use
it? If it were part of an interface for other Elisp to
perhaps use, a global variable is one way of doing
that, but when I wrote it, I have to admit I only made
it global so that both defuns could get access to
it. The only way I can think of not having it that way
is to merge the two defuns, then have them separated
internally with `labels' (`cl-labels'), and used the
one or the other a function of an argument - and that
would be... bulky. If it is OK to use global like this,
should you rely on long and original prefixes to avoid
collisions? Or should you just code whatever you like
and solve collisions if/when they appear? It is not
like this is a Mars expedition or
something. Still... it is the attitude. It doesn't
matter if you recycle cans or do stock exchange, you
want to be all slick just the same.

(setq error-buffer-name "*Errors*")

;; inhibit the debugger -
;;   try this if nothing else: a wonderful thing to not
;;   have it hop out over half the screen for something
;;   that can be communicated in a few words
(setq debug-on-error nil)
(setq eval-expression-debug-on-error nil)

(defun say-and-log-error (data _ fun)
  (let*((error-str (format "%S in %S" data fun))
        (error-buffer (get-buffer-create error-buffer-name))
        (error-win (get-buffer-window error-buffer)) )
    (message error-str)                  ; echo the error message
    (with-current-buffer error-buffer
      (goto-char (point-max))
      (insert error-str "\n") )          ; log it
    (if error-win
        (with-selected-window error-win  ; move focus of error window
          (goto-char (point-max))        ; if visible
          (recenter -1)) )))             ; (is there a better way?)

(setq command-error-function
      (lambda (&rest args)
        (apply #'say-and-log-error args)) )

(defun show-errors ()
  (interactive)
  (switch-to-buffer (get-buffer-create error-buffer-name))
  (goto-char (point-max)) ; the same situation: the last line of data
  (recenter -1) )         ; should be on the last window line
                          ; whenever possible

; test here:
; (message 'error-as-not-string)

-- 
underground experts united

Re: avoiding global variables

[Thien-Thi Nguyen]

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

() Emanuel Berg <embe8573@student.uu.se>
() Mon, 21 Jul 2014 00:48:17 +0200

   If it is OK to use global like this, should you rely
   on long and original prefixes to avoid collisions?
   Or should you just code whatever you like and solve
   collisions if/when they appear?

Heed this:  Do!  Do well!
Wet well: sip, dip, smile, enjoy.
Dry well: bump version.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: if and only if an Error message

[Michael Heerdegen]

Emanuel Berg <embe8573@student.uu.se> writes:

> > Maybe also call `discard-input' as
> > `command-error-default-function' does.
>
> Well, yes, I removed that part from your suggestion
> (not `discard-input' but the whole part with
> `command-error-default-function') because I don't have
> that, neither as a function or a variable. Do you have
> it? What is it?

A function.  I didn't check -- it doesn't exist in the current release,
but will be in the next one.

Until then, I suggest you call `discard-input'.


> > And (message "%s" error-str).
> >              ^^^^
>
> Isn't it already a string from this?

That's not the point.  The first arg of `message' is treated as a
"format control string".  If there's a "%" char in `error-str', you'll
get an error with your version.

Re: avoiding global variables

[Emanuel Berg]

Thien-Thi Nguyen <ttn@gnu.org> writes:

> Heed this: Do!  Do well!  Wet well: sip, dip, smile,
> enjoy.  Dry well: bump version.

Perhaps reading the Elisp manual _is_ a good idea...

-- 
underground experts united

Re: if and only if an Error message

[Emanuel Berg]

Michael Heerdegen <michael_heerdegen@web.de> writes:

>> Isn't it already a string from this?
>
> That's not the point.  The first arg of `message' is
> treated as a "format control string".  If there's a
> "%" char in `error-str', you'll get an error with
> your version.

Aha, OK! I have used that combination habitually for
ages so then I have some search and replacing to do...

-- 
underground experts united