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

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

[Emanuel Berg]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> I cannot reproduce it with emacs -Q nor give a MWE
> (unfortunately)

Start thinking what configuration and/or extension
might come into play.

It would be a natural thing to begin with your
initialization for Org-mode, but... should that really
matter to `query-replace'?

> 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

What did you query, and replace? And for what buffer,
what modes, etc.? Can you reproduce it by doing the
exact same thing?

-- 
underground experts united

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:

> 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

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

[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

[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

[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
>> 
>> 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: 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.