Re: [O] still seeing semi-regular lockups

2014-07-25 Thread Sebastien Vauban
Nicolas Goaziou wrote:
 York Zhao gtdplatf...@gmail.com writes:

 I'm sorry but I really shouldn't send this document to anyone other than a
 lawyer :-)

 [...]

 Just want to confirm that you want me to run this command in that buffer
 and see
 if the problem can be reproduced?

 Calling the provided command on your sensitive buffer will create a copy
 in a temporary buffer with all its contents hidden, just preserving
 structure.

 If you can reproduce the problem in this new buffer and no information
 leaked (the command is just a quick hack so be sure to check it is
 fine), you can send its the contents. There are bonus points if you can
 also explain me how to reproduce it.

I tested your functions on my huge Org LP file for my Emacs config. It
does work as a charm, preserving code blocks (necessary for
reproducibility purpose).

I think this should clearly make its way into Org code base...

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] still seeing semi-regular lockups

2014-07-19 Thread York Zhao
 FWIW, I'm still getting regular lockups with the cache. I'll dig into it
 further when I have time.

I'm still being locked up from time to time, maybe less than before I guess.
What I said was that I never got the deadly problem of Lisp nesting exceeds
`max-lisp-eval-depth, and the fix had been a life saver for me.


Re: [O] still seeing semi-regular lockups

2014-07-18 Thread Matt Lundin
York Zhao gtdplatf...@gmail.com writes:

 On Mon, Jun 30, 2014 at 8:43 PM, York Zhao gtdplatf...@gmail.com
 wrote:

 I got the problem today, with org-mode version 815c218 in Emacs
 24.3.1. The
 error message is: if: Lisp nesting exceeds `max-lisp-eval-depth'.
 Attached is
 the backtrace saved in a file. Hope this will help.

 Just an update. I haven't been bitten by this deadly problem for
 awhile, highly
 likely that it had been fixed. Thanks a lot.

FWIW, I'm still getting regular lockups with the cache. I'll dig into it
further when I have time.

Matt



Re: [O] still seeing semi-regular lockups

2014-07-14 Thread York Zhao
 On Mon, Jun 30, 2014 at 8:43 PM, York Zhao gtdplatf...@gmail.com wrote:

 I got the problem today, with org-mode version 815c218 in Emacs 24.3.1.
The
 error message is: if: Lisp nesting exceeds `max-lisp-eval-depth'.
Attached is
 the backtrace saved in a file. Hope this will help.

Just an update. I haven't been bitten by this deadly problem for awhile,
highly
likely that it had been fixed. Thanks a lot.

York


Re: [O] still seeing semi-regular lockups

2014-07-07 Thread York Zhao
 + zfill-org-paragraph-boundary  7,240
0%
 What is that, if I may ask?

That's in my `zfill-mode' based on `refill-mode', and the function is part
of
the machinery to handle the automatic refilling of org paragraph.

 + ac-handle-post-command 2985  56%
 + timer-event-handler1786  33%
 + redisplay_internal (C function) 131   2%
[...]

 So I suspected the `auto-complete'. I tried M-x auto-complete to turn it
off
 which worked, the typing was fast again. M-x auto-complete to turn it
back on
 and typing became extremely slow again.

 Indeed. auto-complete developers may be interested in your report. This
is not
 an Org bug, though.

Yes, it is highly possible to be a bug in `auto-complete' and I will report
it
to the `auto-complete' developers as soon as I get a bit more time. And I
totally understand if you decide not to spend time on this until I can
further
prove that this is still an org-mode problem. However, I think it might be
too
early to draw the conclusion at this point that this has nothing to do with
org-mode. This is because `auto-complete' started to manifest the problem
after
doing a bunch of org-mode specific operations, more specifically, after
running
`org-drlll' on 8 `org-mode' buffers, which suggested the possibility of the
leftover side effect introduced by org-mode operations. And the problem
could be
in `org-drlll', but also very possibly be in org-mode core because
`org-drlll'
uses the APIs provided by `org-mode' core.

Anyways, the other one I reported yesterday seemed to be related to
org-element
cache stuff and I will follow your suggestion to try to reproduce it. But I
may
not have much time this week anymore. Will definitely try it this weekend
for
sure.

Regards,

York


Re: [O] still seeing semi-regular lockups

2014-07-06 Thread Nicolas Goaziou
Hello,

York Zhao gtdplatf...@gmail.com writes:

 I'm now using commit fdc673d. The problem I experienced 2 days ago happened
 again. The direct operations I did was that I programmatically deleted a few
 table line in one table and inserted them in another table which is in the
 subtree immediately following the current table. But I ended up having more
 lines in the new table, most of them were duplicated. Here is roughly the
 snippet of the command I used:

[...]

 I can't post everything here because the command operates on my personal
 contents. I have been using this snippet for years without problem. I executed
 this command several times with point moved to different lines in the first
 table. Each time this command is executed it is supposed to move one table
 line to another table.

 Hope this will help a bit and I will pay close attention next time to give 
 more
 details.

Thank you for the report. I wasn't able to reproduce it with latest
commit (df9ccbd). Could you try again and see if it fixes your problem?


Regards,

-- 
Nicolas Goaziou



Re: [O] still seeing semi-regular lockups

2014-07-06 Thread Nicolas Goaziou
Hello,

York Zhao gtdplatf...@gmail.com writes:

 The exact same slowness problem happened just now. M-x 
 org-element-cache-reset
 didn't have any effect. Nor did setting `org-element-use-cache' to nil. Again,
 killed the buffer and reopened didn't help.

It looks like the problem isn't related to the cache then. Anyway, you
could try to do some profiling (see `profiler-start').

 One thing I didn't do, unfortunately, was that I reset cache only for the 
 buffer
 where the slowness manifested. I think I should try reseting cache for all 
 the 8
 buffers too right?

Cache is buffer dependent, so you don't need to reset cache for all of
them (though it's simply C-u M-x org-element-cache-reset).


Regards,

-- 
Nicolas Goaziou



Re: [O] still seeing semi-regular lockups

2014-07-06 Thread York Zhao
 Thank you for the report. I wasn't able to reproduce it with latest commit
 (df9ccbd). Could you try again and see if it fixes your problem?

I haven't experienced this problem since July 3, hopefully it has been
fixed.
Thank you very much for your work.

York


Re: [O] still seeing semi-regular lockups

2014-07-06 Thread York Zhao
  The exact same slowness problem happened just now. M-x
org-element-cache-reset
  didn't have any effect. Nor did setting `org-element-use-cache' to nil.
Again,
  killed the buffer and reopened didn't help.
 It looks like the problem isn't related to the cache then. Anyway, you
 could try to do some profiling (see `profiler-start').

  One thing I didn't do, unfortunately, was that I reset cache only for
the buffer
  where the slowness manifested. I think I should try reseting cache for
all the 8
  buffers too right?
 Cache is buffer dependent, so you don't need to reset cache for all of
 them (though it's simply C-u M-x org-element-cache-reset).

I haven't experienced this problem (I'm now using df9ccbd) since last
time I
reported (July 2 I guess), really hope that this problem has been fixed.
Thank
you very much for all the hard work you have done on this issue.

York


Re: [O] still seeing semi-regular lockups

2014-07-06 Thread York Zhao
The extreme slowness happened again just know. When this happened,
`org-end-of-line' command took forever until C-g. M-x
org-element-cache-reset
worked this time, i.e., after running `org-element-cache-reset' command
`org-end-of-line' became fast again.

I was using commit ca6ecf9, and the buffer was 38xx lines 168K in size.


Re: [O] still seeing semi-regular lockups

2014-07-06 Thread Nicolas Goaziou
Hello,

York Zhao gtdplatf...@gmail.com writes:

 The extreme slowness happened again just know. When this happened,
 `org-end-of-line' command took forever until C-g. M-x
 org-element-cache-reset
 worked this time, i.e., after running `org-element-cache-reset' command
 `org-end-of-line' became fast again.

 I was using commit ca6ecf9, and the buffer was 38xx lines 168K in
 size.

This sounds more like an infloop. Could you send me the document you
were working on[fn:1], in private, and describe what you were doing
before it froze?


Regards,

[fn:1] or at least an equivalent file structure wise, calling the
following function in that document:

  (defun ngz-scramble-contents ()
(interactive)
(let ((tree (org-element-parse-buffer)))
  (org-element-map tree '(code comment comment-block example-block 
fixed-width
   keyword link node-property plain-text 
verbatim)
(lambda (obj)
  (case (org-element-type obj)
((code comment comment-block example-block fixed-width keyword
   node-property verbatim)
 (let ((value (org-element-property :value obj)))
   (org-element-put-property
obj :value (replace-regexp-in-string [[:alnum:]] x value
(link
 (unless (string= (org-element-property :type obj) radio)
   (org-element-put-property obj :raw-link http://orgmode.org;)))
(plain-text
 (org-element-set-element
  obj (replace-regexp-in-string [[:alnum:]] x obj)
nil nil nil t)
  (let ((buffer (get-buffer-create *Scrambled text*)))
(with-current-buffer buffer
  (insert (org-element-interpret-data tree))
  (goto-char (point-min)))
(switch-to-buffer buffer

If you can reproduce the problem in this new buffer, that's fine too.

-- 
Nicolas Goaziou



Re: [O] still seeing semi-regular lockups

2014-07-06 Thread York Zhao
 Could you send me the document you were working on, in private, and
describe
 what you were doing before it froze?

I'm sorry but I really shouldn't send this document to anyone other than a
lawyer :-)

 or at least an equivalent file structure wise, calling the following
function
 in that document ... If you can reproduce the problem in this new buffer,
 that's fine too.

Just want to confirm that you want me to run this command in that buffer
and see
if the problem can be reproduced?


Re: [O] still seeing semi-regular lockups

2014-07-06 Thread York Zhao
  The exact same slowness problem happened just now. M-x
org-element-cache-reset
  didn't have any effect. Nor did setting `org-element-use-cache' to nil.
Again,
  killed the buffer and reopened didn't help.
 It looks like the problem isn't related to the cache then. Anyway, you
 could try to do some profiling (see `profiler-start').

  One thing I didn't do, unfortunately, was that I reset cache only for
the buffer
  where the slowness manifested. I think I should try reseting cache for
all the 8
  buffers too right?
 Cache is buffer dependent, so you don't need to reset cache for all of
 them (though it's simply C-u M-x org-element-cache-reset).

This problem happened again just now. Again, M-x org-element-cache-reset
didn't
help, nor did C-u M-x org-element-cache-reset. And it seemed that only
typing
characters were slow, took 1 or 2 seconds for a typed character to appear
on the
screen.

Again, this happened in the big buffer that has 77,xxx lines, freshly
opened. I
restarted Emacs and finished `org-drill' session on 8 files before opening
this
big file.

I then `M-x profile-start', typed a few letters and `M-x profile-report',
here's
the memory report:

+ #compiled 0x138b23111,320,032  43%
+ call-interactively4,857,849  18%
+ #compiled 0x1444275 2,170,499   8%
+ timer-event-handler   1,428,527   5%
+ #compiled 0xa6e561  1,299,957   5%
+ helm  1,058,503   4%
+ redisplay_internal (C function) 869,652   3%
+ ac-handle-post-command  695,448   2%
+ helm-M-x517,012   2%
+ helm-check-new-input215,112   0%
+ #compiled 0x1391c7d   211,328   0%
+ helm-let-internal   182,580   0%
+ helm-read-pattern-maybe 109,907   0%
+ helm-process-filtered-candidate-transformer  97,992   0%
+ helm-get-cached-candidates   87,872   0%
+ cl-mapcar82,880   0%
+ helm-update  81,536   0%
+ helm-funcall-with-source 72,380   0%
+ read-from-minibuffer 70,224   0%
+ funcall  69,721   0%
+ apply34,618   0%
+ #compiled 0xfe8ee9 33,140   0%
+ helm--compute-sources31,988   0%
+ yas--post-command-handler29,288   0%
+ org-element--parse-to29,184   0%
+ #compiled 0xfe83ad 12,520   0%
+ helm-compute-matches 12,400   0%
+ let  12,288   0%
+ byte-code 9,320   0%
+ ac-handle-pre-command 9,298   0%
+ profiler-report-rerender-calltree 8,188   0%
+ command-execute   8,188   0%
+ helm-check-minibuffer-input   8,152   0%
+ zfill-org-paragraph-boundary  7,240   0%
+ helm-internal 7,000   0%
+ sp--self-insert-command   6,060   0%
+ helm-comp-read5,200   0%
+ let*  5,028   0%
+ catch 4,204   0%
+ hl-paren-highlight4,144   0%
+ zfill-pre-command-function4,096   0%
+ save-restriction  4,096   0%
+ while 4,096   0%
+ save-excursion4,096   0%
+ helm-M-x-current-mode-map-alist   3,144   0%
+ helm-display-buffer   2,080   0%
+ profiler-report-setup-buffer  1,066   0%
+ profiler-report   1,054   0%
+ org-element--cache-before-change  1,024   0%

And CPU report:

+ ac-handle-post-command 2985  56%
+ timer-event-handler

Re: [O] still seeing semi-regular lockups

2014-07-06 Thread Nicolas Goaziou
Hello,

York Zhao gtdplatf...@gmail.com writes:

 I'm sorry but I really shouldn't send this document to anyone other than a
 lawyer :-)

[...]

 Just want to confirm that you want me to run this command in that buffer
 and see
 if the problem can be reproduced?

Calling the provided command on your sensitive buffer will create a copy
in a temporary buffer with all its contents hidden, just preserving
structure.

If you can reproduce the problem in this new buffer and no information
leaked (the command is just a quick hack so be sure to check it is
fine), you can send its the contents. There are bonus points if you can
also explain me how to reproduce it.


Regards,

-- 
Nicolas Goaziou



Re: [O] still seeing semi-regular lockups

2014-07-06 Thread Nicolas Goaziou
York Zhao gtdplatf...@gmail.com writes:

 Again, this happened in the big buffer that has 77,xxx lines, freshly
 opened. I
 restarted Emacs and finished `org-drill' session on 8 files before opening
 this
 big file.

 I then `M-x profile-start', typed a few letters and `M-x profile-report',
 here's
 the memory report:

[...]

 + zfill-org-paragraph-boundary  7,240   0%

What is that, if I may ask?

 + ac-handle-post-command 2985  56%
 + timer-event-handler1786  33%
 + redisplay_internal (C function) 131   2%

[...]

 So I suspected the `auto-complete'. I tried M-x auto-complete to turn it off
 which worked, the typing was fast again. M-x auto-complete to turn it back
 on
 and typing became extremely slow again.

Indeed. auto-complete developers may be interested in your report. This
is not an Org bug, though.


Regards,

-- 
Nicolas Goaziou



Re: [O] still seeing semi-regular lockups

2014-07-03 Thread York Zhao
 I'm now using commit 126e2bc, this morning I did experience some funny
 things which I had never experienced before. Unfortunately I let them go. I
 will keep an eye on the new problems.

I'm now using commit fdc673d. The problem I experienced 2 days ago happened
again. The direct operations I did was that I programmatically deleted a few
table line in one table and inserted them in another table which is in the
subtree immediately following the current table. But I ended up having more
lines in the new table, most of them were duplicated. Here is roughly the
snippet of the command I used:

(defun yhj-drop-something ()
  (interactive)
  (save-excursion
(let* ((beg (line-beginning-position))
   (end (1+ (line-end-position)))
   (line (buffer-substring beg end)))
  (kill-region beg end)
  (unless (re-search-forward ^\\*+[ \t]+Newtable[ \t]*$
 (save-excursion
   (org-end-of-subtree t)) t)
(error Incompatible contents format))
  (forward-line 4)
  (unless (org-at-table-p 'any)
(error Incompatible contents format))
  (beginning-of-line)
  (insert line)
  (org-table-align)
  (org-table-sort-lines nil ?a

I can't post everything here because the command operates on my personal
contents. I have been using this snippet for years without problem. I executed
this command several times with point moved to different lines in the first
table. Each time this command is executed it is supposed to move one table
line to another table.

Hope this will help a bit and I will pay close attention next time to give more
details.



Re: [O] still seeing semi-regular lockups

2014-07-03 Thread York Zhao
 I'm now using commit fdc673d. The problem I experienced 2 days ago happened
 again. The direct operations I did was that I programmatically deleted a few
 table line in one table and inserted them in another table which is in the
 subtree immediately following the current table. But I ended up having more
 lines in the new table, most of them were duplicated. Here is roughly the
 snippet of the command I used:

 (defun yhj-drop-something ()
   (interactive)
   (save-excursion
 (let* ((beg (line-beginning-position))
(end (1+ (line-end-position)))
(line (buffer-substring beg end)))
   (kill-region beg end)
   (unless (re-search-forward ^\\*+[ \t]+Newtable[ \t]*$
  (save-excursion
(org-end-of-subtree t)) t)
 (error Incompatible contents format))
   (forward-line 4)
   (unless (org-at-table-p 'any)
 (error Incompatible contents format))
   (beginning-of-line)
   (insert line)
   (org-table-align)
   (org-table-sort-lines nil ?a

I just noticed these errors in my *messages* buffer:

user-error: Not in table data field
2 lines sorted, based on column 1
Starting egrep process...
3 lines sorted, based on column 1
4 lines sorted, based on column 1
After 0 kbd macro iterations: let: Wrong type argument: number-or-marker-p, nil
Error in post-command-hook (zfill-post-command-function): (user-error
An element cannot be parsed line 76823)
Error in pre-command-hook (zfill-pre-command-function): (user-error
An element cannot be parsed line 76823)
6 lines sorted, based on column 1

I'm not sure if the `(user-error An element cannot be parsed line 76823)' can
be of any help. Line 76823 was the last line in the table where the table lines
were being moved to (the Destination Table). This table looks like thin:

*** Source Table
|-+-+-+-+---|
| COL1| COL2| COL3| COL4|   |
|-+-+-+-+---|
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
|-+-+-+-+---|

 Destination Table
|-+-+-+-+---|
| COL1| COL2| COL3| COL4|   |
|-+-+-+-+---|
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
|-+-+-+-+---|



Re: [O] still seeing semi-regular lockups

2014-07-02 Thread Nicolas Goaziou
Hello,

York Zhao gtdplatf...@gmail.com writes:

 Just suffered from extreme slowness. My Emacs had been running for about 1 
 hour
 and I was having two org-mode buffers, one file has 3800 lines, 168 KB bytes.
 And the other has 76,600 lines, 4,267,327 KB bytes. Both files had been opened
 for awhile. Didn't have problem in the beginning, but then typing in the 
 bigger
 buffer became extremely slow, took at least one to two seconds for a typed
 character to be displayed on the screen. Killed the buffer and then reopen it
 didn't help at all. At the same time typing in the other smaller buffer didn't
 have the same slowness issue. Restarted Emacs and the issue disappeared.

 One of the problem I have noticed for a long time is that org-mode could 
 become
 slower and slower with use, which was exactly what I had been experiencing 
 just
 now.

OK. If you experience it again, please do

  M-x org-element-cache-reset

in the slow buffer and see if it is responsive again.

Another interesting test would be to try reproducing the problem with 
`org-element-use-cache'
set to nil.

I'm not totally sure this is related to the cache, as killing the buffer
should have solved the problem.


Regards,

-- 
Nicolas Goaziou



Re: [O] still seeing semi-regular lockups

2014-07-02 Thread York Zhao
 OK. If you experience it again, please do

   M-x org-element-cache-reset

 in the slow buffer and see if it is responsive again.

 Another interesting test would be to try reproducing the problem with
 `org-element-use-cache' set to nil.

The exact same slowness problem happened just now. M-x org-element-cache-reset
didn't have any effect. Nor did setting `org-element-use-cache' to nil. Again,
killed the buffer and reopened didn't help.

I couldn't remember whether the big file was already opened, but I think it was
not opened yet, i.e., when the problem occurred, the file might just be opened.
What I did was that I started Emacs, run `org-drill' across 8 files (in one
session). Total size of these files was 730 KB bytes. The good thing was that
the session was finished successfully, no max-lisp-eval-depth error, and I
really hope this deadly error will never happen.

One thing I didn't do, unfortunately, was that I reset cache only for the buffer
where the slowness manifested. I think I should try reseting cache for all the 8
buffers too right?

York



Re: [O] still seeing semi-regular lockups

2014-07-01 Thread Nicolas Goaziou
Hello,

York Zhao gtdplatf...@gmail.com writes:

 I got the problem today, with org-mode version 815c218 in Emacs 24.3.1. The
 error message is: if: Lisp nesting exceeds `max-lisp-eval-depth'. Attached is
 the backtrace saved in a file.

Please update, if you can. I pushed a couple of fixes a few hours ago.
It may solve the problem.


Regards,

-- 
Nicolas Goaziou



Re: [O] still seeing semi-regular lockups

2014-07-01 Thread York Zhao
 Please update, if you can. I pushed a couple of fixes a few hours ago. It may
 solve the problem.

I noticed the new commits after my previous report. I'm now using commit
126e2bc, this morning I did experience some funny things which I had never
experienced before. Unfortunately I let them go. I will keep an eye on the new
problems.



Re: [O] still seeing semi-regular lockups

2014-07-01 Thread York Zhao
Just suffered from extreme slowness. My Emacs had been running for about 1 hour
and I was having two org-mode buffers, one file has 3800 lines, 168 KB bytes.
And the other has 76,600 lines, 4,267,327 KB bytes. Both files had been opened
for awhile. Didn't have problem in the beginning, but then typing in the bigger
buffer became extremely slow, took at least one to two seconds for a typed
character to be displayed on the screen. Killed the buffer and then reopen it
didn't help at all. At the same time typing in the other smaller buffer didn't
have the same slowness issue. Restarted Emacs and the issue disappeared.

One of the problem I have noticed for a long time is that org-mode could become
slower and slower with use, which was exactly what I had been experiencing just
now.



Re: [O] still seeing semi-regular lockups

2014-06-30 Thread Alan Schmitt
On 2014-06-30 03:43, York Zhao gtdplatf...@gmail.com writes:

 I know that doesn't help much except for confirming the problem other people 
 was
 suffering. Sorry for the rant. I was too busy and too frustrated.

 By the way, what does ECM stands for?

Exemple Complet Minimal (French for minimal complete example)

http://orgmode.org/worg/org-faq.html#ecm

Best,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7


pgpfvOW25eEeI.pgp
Description: PGP signature


Re: [O] still seeing semi-regular lockups

2014-06-29 Thread Nicolas Goaziou
Hello,

York Zhao gtdplatf...@gmail.com writes:

 My experience of using `org-mode' (git commit 2824502 and previous versions)
 with Emacs 24.3.91 (git commit 0f0917d) had been a nightmare. I got bitten 
 by
 this bug frequently, I was mad.

I'm sorry about this.

However, just saying that it had been a nightmare doesn't help much.
If you can, please try to provide an ECM. I will gladly fix any bug
I can reproduce.

 This was a problem with Emacs 24.3.1 (3a1ce06) too

Note that this is an entirely different issue, since maint branch
doesn't have a cache. Reporting bugs found there is even more critical
as it is the version that will be shipped with next Emacs release.


Regards,

-- 
Nicolas Goaziou



Re: [O] still seeing semi-regular lockups

2014-06-29 Thread York Zhao
 Yeah, I'm using git emacs, labeled 24.4.50.1

Did you compile Emacs from git? I have never seen the tag 24.4.50.1, are you
sure you didn't have a typo here?

On Sat, Jun 28, 2014 at 10:23 PM, Eric Abrahamsen
e...@ericabrahamsen.net wrote:
 York Zhao gtdplatf...@gmail.com writes:

 My experience of using `org-mode' (git commit 2824502 and previous 
 versions)
 with Emacs 24.3.91 (git commit 0f0917d) had been a nightmare. I got bitten 
 by
 this bug frequently, I was mad. Some of my `org-drill' entires might have 
 been
 damaged to some extent. This was a problem with Emacs 24.3.1 (3a1ce06) too 
 but
 was much better, at least not damaging my `org-drill' flies. I will have to 
 go
 back to Emacs 24.3.1. Appears to me that Emacs 24.4 may have some bad issues.

 Yeah, I'm using git emacs, labeled 24.4.50.1.

 On Sat, Jun 28, 2014 at 3:27 PM, Eric Abrahamsen
 e...@ericabrahamsen.net wrote:
 Eric Abrahamsen e...@ericabrahamsen.net writes:

 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 None of those three, I'm afraid! It was hanging on a variety of editing
 operations that, as far as I can tell, had little in common. There's a
 possibility that they were list-item-related, but really there wasn't
 much commonality.

 FYI, I recently fixed a bug[fn:1] that could introduce uncommon random
 lockups. Hopefully, it may be related to your problem (which is
 different from Daimrod's).

 Thanks for the followup! I was watching Daimrod's thread, and also
 Matt's most recent posting -- that also seemed more relevant to my
 problems, which were almost solely confined to log/state notes. I've
 pulled the fix, and will let you know if I see any more problems.

 After feeling like I was running behind the bus for a few weeks, I may
 have finally gotten something useful.

 FWIW I *haven't* seen any log-drawer related lockups for a while now,
 not since Nicolas said he fixed some things in that direction. But in
 the past couple of days I have had a few flyspell-related lockups, and
 finally got an uncompiled backtrace.

 This has happened the same way a few times now. A longish, text-heavy
 file, with only three top-level headlines (one of them a footnote
 section), and no drawers of any sort anywhere in the document -- very
 little Org markup at all, actually. The lockup starts at random, and
 SIGUSR2 shows me a very short backtrace related to a flyspell-mode
 related advice somewhere (I didn't save this one, it's byte-compiled, if
 it's important I'll clean out more compiled files and try to get it
 again).

 I recover from that lock, turn off flyspell-mode in my org buffer, and
 within three or four commands Org locks up again. This time the
 backtrace is related to org cache, here's the one I just got, after
 calling org-end-of-line:

 http://pastebin.com/Q0g8DmUa

 Hope that's useful! Let me know if I can provide anything else.

 E







Re: [O] still seeing semi-regular lockups

2014-06-29 Thread York Zhao
I know that doesn't help much except for confirming the problem other people was
suffering. Sorry for the rant. I was too busy and too frustrated.

By the way, what does ECM stands for?

 This is an entirely different issue, since maint branch doesn't have a cache.

I must clarify that what I meant was that I used exactly the same version of
`org-mode', from git repository, with the two Emacs versions. That said, I never
used the `org-mode' version bundled with Emacs. I'm sorry for the confusion.

1. Sometimes when Emacs hangs in `org-mode', C-g wouldn't work. Waited
patiently for awhile and C-g work again. Pressing C-g produced the error
message: Error in post-command-hook (zfill-post-command-function): (quit).
Emacs hanged again, waited patiently for awhile until C-g worked again and
Emacs revived, but in an unstable state.

2. Other times when Emacs hangs in `org-mode', C-g wouldn't work until after
perhaps 20 seconds or so, hitting C-g breaks out. Emacs enters a useless
state, nothing works even C-x C-c doesn't work, but produces error: Variable
bind exceeds maximum level or something.

A few hours ago I switched back to Emacs 24.3.1, problem 1 happened once, but
never had problem 2. And editing in `org-mode' was several times more smooth and
faster. Way better. Again, I want to stress, I was using the same `org-mode'
from git repository (commit 2824502).

Hope this would help a little bit.

On Sun, Jun 29, 2014 at 9:15 PM, York Zhao gtdplatf...@gmail.com wrote:
 Yeah, I'm using git emacs, labeled 24.4.50.1

 Did you compile Emacs from git? I have never seen the tag 24.4.50.1, are you
 sure you didn't have a typo here?

 On Sat, Jun 28, 2014 at 10:23 PM, Eric Abrahamsen
 e...@ericabrahamsen.net wrote:
 York Zhao gtdplatf...@gmail.com writes:

 My experience of using `org-mode' (git commit 2824502 and previous 
 versions)
 with Emacs 24.3.91 (git commit 0f0917d) had been a nightmare. I got 
 bitten by
 this bug frequently, I was mad. Some of my `org-drill' entires might have 
 been
 damaged to some extent. This was a problem with Emacs 24.3.1 (3a1ce06) 
 too but
 was much better, at least not damaging my `org-drill' flies. I will have to 
 go
 back to Emacs 24.3.1. Appears to me that Emacs 24.4 may have some bad 
 issues.

 Yeah, I'm using git emacs, labeled 24.4.50.1.

 On Sat, Jun 28, 2014 at 3:27 PM, Eric Abrahamsen
 e...@ericabrahamsen.net wrote:
 Eric Abrahamsen e...@ericabrahamsen.net writes:

 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 None of those three, I'm afraid! It was hanging on a variety of editing
 operations that, as far as I can tell, had little in common. There's a
 possibility that they were list-item-related, but really there wasn't
 much commonality.

 FYI, I recently fixed a bug[fn:1] that could introduce uncommon random
 lockups. Hopefully, it may be related to your problem (which is
 different from Daimrod's).

 Thanks for the followup! I was watching Daimrod's thread, and also
 Matt's most recent posting -- that also seemed more relevant to my
 problems, which were almost solely confined to log/state notes. I've
 pulled the fix, and will let you know if I see any more problems.

 After feeling like I was running behind the bus for a few weeks, I may
 have finally gotten something useful.

 FWIW I *haven't* seen any log-drawer related lockups for a while now,
 not since Nicolas said he fixed some things in that direction. But in
 the past couple of days I have had a few flyspell-related lockups, and
 finally got an uncompiled backtrace.

 This has happened the same way a few times now. A longish, text-heavy
 file, with only three top-level headlines (one of them a footnote
 section), and no drawers of any sort anywhere in the document -- very
 little Org markup at all, actually. The lockup starts at random, and
 SIGUSR2 shows me a very short backtrace related to a flyspell-mode
 related advice somewhere (I didn't save this one, it's byte-compiled, if
 it's important I'll clean out more compiled files and try to get it
 again).

 I recover from that lock, turn off flyspell-mode in my org buffer, and
 within three or four commands Org locks up again. This time the
 backtrace is related to org cache, here's the one I just got, after
 calling org-end-of-line:

 http://pastebin.com/Q0g8DmUa

 Hope that's useful! Let me know if I can provide anything else.

 E







Re: [O] still seeing semi-regular lockups

2014-06-28 Thread Eric Abrahamsen
Eric Abrahamsen e...@ericabrahamsen.net writes:

 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 None of those three, I'm afraid! It was hanging on a variety of editing
 operations that, as far as I can tell, had little in common. There's a
 possibility that they were list-item-related, but really there wasn't
 much commonality.

 FYI, I recently fixed a bug[fn:1] that could introduce uncommon random
 lockups. Hopefully, it may be related to your problem (which is
 different from Daimrod's).

 Thanks for the followup! I was watching Daimrod's thread, and also
 Matt's most recent posting -- that also seemed more relevant to my
 problems, which were almost solely confined to log/state notes. I've
 pulled the fix, and will let you know if I see any more problems.

After feeling like I was running behind the bus for a few weeks, I may
have finally gotten something useful.

FWIW I *haven't* seen any log-drawer related lockups for a while now,
not since Nicolas said he fixed some things in that direction. But in
the past couple of days I have had a few flyspell-related lockups, and
finally got an uncompiled backtrace.

This has happened the same way a few times now. A longish, text-heavy
file, with only three top-level headlines (one of them a footnote
section), and no drawers of any sort anywhere in the document -- very
little Org markup at all, actually. The lockup starts at random, and
SIGUSR2 shows me a very short backtrace related to a flyspell-mode
related advice somewhere (I didn't save this one, it's byte-compiled, if
it's important I'll clean out more compiled files and try to get it
again).

I recover from that lock, turn off flyspell-mode in my org buffer, and
within three or four commands Org locks up again. This time the
backtrace is related to org cache, here's the one I just got, after
calling org-end-of-line:

http://pastebin.com/Q0g8DmUa

Hope that's useful! Let me know if I can provide anything else.

E




Re: [O] still seeing semi-regular lockups

2014-06-28 Thread York Zhao
My experience of using `org-mode' (git commit 2824502 and previous versions)
with Emacs 24.3.91 (git commit 0f0917d) had been a nightmare. I got bitten by
this bug frequently, I was mad. Some of my `org-drill' entires might have been
damaged to some extent. This was a problem with Emacs 24.3.1 (3a1ce06) too but
was much better, at least not damaging my `org-drill' flies. I will have to go
back to Emacs 24.3.1. Appears to me that Emacs 24.4 may have some bad issues.

On Sat, Jun 28, 2014 at 3:27 PM, Eric Abrahamsen
e...@ericabrahamsen.net wrote:
 Eric Abrahamsen e...@ericabrahamsen.net writes:

 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 None of those three, I'm afraid! It was hanging on a variety of editing
 operations that, as far as I can tell, had little in common. There's a
 possibility that they were list-item-related, but really there wasn't
 much commonality.

 FYI, I recently fixed a bug[fn:1] that could introduce uncommon random
 lockups. Hopefully, it may be related to your problem (which is
 different from Daimrod's).

 Thanks for the followup! I was watching Daimrod's thread, and also
 Matt's most recent posting -- that also seemed more relevant to my
 problems, which were almost solely confined to log/state notes. I've
 pulled the fix, and will let you know if I see any more problems.

 After feeling like I was running behind the bus for a few weeks, I may
 have finally gotten something useful.

 FWIW I *haven't* seen any log-drawer related lockups for a while now,
 not since Nicolas said he fixed some things in that direction. But in
 the past couple of days I have had a few flyspell-related lockups, and
 finally got an uncompiled backtrace.

 This has happened the same way a few times now. A longish, text-heavy
 file, with only three top-level headlines (one of them a footnote
 section), and no drawers of any sort anywhere in the document -- very
 little Org markup at all, actually. The lockup starts at random, and
 SIGUSR2 shows me a very short backtrace related to a flyspell-mode
 related advice somewhere (I didn't save this one, it's byte-compiled, if
 it's important I'll clean out more compiled files and try to get it
 again).

 I recover from that lock, turn off flyspell-mode in my org buffer, and
 within three or four commands Org locks up again. This time the
 backtrace is related to org cache, here's the one I just got, after
 calling org-end-of-line:

 http://pastebin.com/Q0g8DmUa

 Hope that's useful! Let me know if I can provide anything else.

 E





Re: [O] still seeing semi-regular lockups

2014-06-28 Thread Eric Abrahamsen
York Zhao gtdplatf...@gmail.com writes:

 My experience of using `org-mode' (git commit 2824502 and previous versions)
 with Emacs 24.3.91 (git commit 0f0917d) had been a nightmare. I got bitten 
 by
 this bug frequently, I was mad. Some of my `org-drill' entires might have been
 damaged to some extent. This was a problem with Emacs 24.3.1 (3a1ce06) too 
 but
 was much better, at least not damaging my `org-drill' flies. I will have to go
 back to Emacs 24.3.1. Appears to me that Emacs 24.4 may have some bad issues.

Yeah, I'm using git emacs, labeled 24.4.50.1.

 On Sat, Jun 28, 2014 at 3:27 PM, Eric Abrahamsen
 e...@ericabrahamsen.net wrote:
 Eric Abrahamsen e...@ericabrahamsen.net writes:

 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 None of those three, I'm afraid! It was hanging on a variety of editing
 operations that, as far as I can tell, had little in common. There's a
 possibility that they were list-item-related, but really there wasn't
 much commonality.

 FYI, I recently fixed a bug[fn:1] that could introduce uncommon random
 lockups. Hopefully, it may be related to your problem (which is
 different from Daimrod's).

 Thanks for the followup! I was watching Daimrod's thread, and also
 Matt's most recent posting -- that also seemed more relevant to my
 problems, which were almost solely confined to log/state notes. I've
 pulled the fix, and will let you know if I see any more problems.

 After feeling like I was running behind the bus for a few weeks, I may
 have finally gotten something useful.

 FWIW I *haven't* seen any log-drawer related lockups for a while now,
 not since Nicolas said he fixed some things in that direction. But in
 the past couple of days I have had a few flyspell-related lockups, and
 finally got an uncompiled backtrace.

 This has happened the same way a few times now. A longish, text-heavy
 file, with only three top-level headlines (one of them a footnote
 section), and no drawers of any sort anywhere in the document -- very
 little Org markup at all, actually. The lockup starts at random, and
 SIGUSR2 shows me a very short backtrace related to a flyspell-mode
 related advice somewhere (I didn't save this one, it's byte-compiled, if
 it's important I'll clean out more compiled files and try to get it
 again).

 I recover from that lock, turn off flyspell-mode in my org buffer, and
 within three or four commands Org locks up again. This time the
 backtrace is related to org cache, here's the one I just got, after
 calling org-end-of-line:

 http://pastebin.com/Q0g8DmUa

 Hope that's useful! Let me know if I can provide anything else.

 E






Re: [O] still seeing semi-regular lockups

2014-06-27 Thread Nicolas Goaziou
Hello,

Matt Lundin m...@imapmail.org writes:

 With killall -USR2 emacs, the following backtrace popped up, which
 highlights flyspell as the culrpit. Note: I have flyspell turned on in
 all text buffers, but I have (for several months) only experienced
 lockups when using org-mode. I spend more time in TeX buffers than in
 org-mode, and I have never had a lockup with AUCTeX.

 * (setq quit-flag t)
   (condition-case nil (let ((inhibit-quit nil)) (let ((command
   this-command) deactivate-mark) (if (flyspell-check-pre-word-p)
   (save-excursion (quote (flyspell-debug-signal-pre-word-checked))
   (goto-char flyspell-pre-point) (flyspell-word))) (if

[...]

Thank you for the report.

Unfortunately, this backtrace doesn't help much. Even if it referred
explicitly to a cache-related function, it would likely not explain the
reasons behind the cache corruption. I need an ECM (even if the bug
isn't 100 % reproducible) for that.

In the meantime, if you can, please update Org regularly, as I'm
reviewing the code and will probably make changes along the way.


Regards,

-- 
Nicolas Goaziou



Re: [O] still seeing semi-regular lockups

2014-06-27 Thread Nicolas Goaziou


Hello,

Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org
writes:

 I also still experience semi-regular Emacs infloops, particularly when
 editing clocking entries manually (with the arrow keys), in the LOGBOOK
 drawer. It's quite often in such a situation, though not 100%
 reproducible.

I tried but couldn't reproduce it. Please provide an ECM (even without
100 % success) if you can.

 - Org-mode version 8.2.7 (release_8.2.7-1119-gfcc51c/) -- though I'll
   update right now!

Please do. I made some changes to the code recently.


Regards,

-- 
Nicolas Goaziou




Re: [O] still seeing semi-regular lockups

2014-06-27 Thread Alan Schmitt
I've also just been bitten by this bug, as I was doing my weekly
review. I'll try to see if I can write an ECM, but for the record this
is what I was doing: I was in an agenda view sorted by the value of
a LAST_REVIEW property, and I was repeatedly calling this function on
the entries of the view:

#+begin_src emacs-lisp
(defun org-review-insert-last-review (optional prompt)
  Insert the current date as last review. If prefix argument:
prompt the user for the date. If `org-review-sets-next-date' is
set to `t', also insert a next review date.
  (interactive P)
  (let ((ts (if prompt
(concat  (org-read-date) )
  (format-time-string (car org-time-stamp-formats)
(org-review-insert-date org-review-last-property-name
org-review-last-timestamp-format
ts)
(when org-review-sets-next-date
  (org-review-insert-date
   org-review-next-property-name
   org-review-next-timestamp-format
   (format-time-string (car org-time-stamp-formats)
   (org-review-last-planned 
ts
(or (org-review-review-delay-prop
 (if (equal (buffer-name) 
org-agenda-buffer-name)
 (or (org-get-at-bol 'org-marker)
 (org-agenda-error))
   (point)))
org-review-delay)))
#+end_src

the `org-review-insert-date` is defined as follows

#+begin_src emacs-lisp
(defun org-review-insert-date (propname fmt date)
  Insert the DATE under property PROPNAME, in the format
specified by FMT.
  (org-entry-put
   (if (equal (buffer-name) org-agenda-buffer-name)
   (or (org-get-at-bol 'org-marker)
   (org-agenda-error))
 (point))
   propname
   (cond
((eq fmt 'inactive)
 (concat [ (substring date 1 -1) ]))
((eq fmt 'active) date)
(t (substring date 1 -1)
#+end_src

I could get out of the loop using ctrl-G but any further interaction
with the todo buffer (expanding the task to see its properties, or
changing the todo state) would result in further lockup. Restarting
emacs let me do a few more entries (about a dozen) before it locked up
again.

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7


pgpC5w4GYRVZA.pgp
Description: PGP signature


Re: [O] still seeing semi-regular lockups

2014-06-27 Thread Nicolas Goaziou
Hello,

Alan Schmitt alan.schm...@polytechnique.org writes:

 I've also just been bitten by this bug, as I was doing my weekly
 review. I'll try to see if I can write an ECM, but for the record this
 is what I was doing: I was in an agenda view sorted by the value of
 a LAST_REVIEW property, and I was repeatedly calling this function on
 the entries of the view:

[...]

 I could get out of the loop using ctrl-G but any further interaction
 with the todo buffer (expanding the task to see its properties, or
 changing the todo state) would result in further lockup. Restarting
 emacs let me do a few more entries (about a dozen) before it locked up
 again.

This bug should be fixed (`org-entry-put' corrupted the cache). Thank
you for reporting it.


Regards,

-- 
Nicolas Goaziou



Re: [O] still seeing semi-regular lockups

2014-06-25 Thread Sebastien Vauban
Matt Lundin wrote:
 Eric Abrahamsen e...@ericabrahamsen.net writes:
 Nicolas Goaziou m...@nicolasgoaziou.fr writes:
 Eric Abrahamsen e...@ericabrahamsen.net writes:

 None of those three, I'm afraid! It was hanging on a variety of editing
 operations that, as far as I can tell, had little in common. There's a
 possibility that they were list-item-related, but really there wasn't
 much commonality.

 FYI, I recently fixed a bug[fn:1] that could introduce uncommon random
 lockups. Hopefully, it may be related to your problem (which is
 different from Daimrod's).

 Thanks for the followup! I was watching Daimrod's thread, and also
 Matt's most recent posting -- that also seemed more relevant to my
 problems, which were almost solely confined to log/state notes. I've
 pulled the fix, and will let you know if I see any more problems.

 With the latest git, I've experienced three lock-ups/freezes this
 evening when a) archiving a subtree to a file, b) changing a todo state
 with repeating timestamp, and 3) calling C-c C-c in an org-capture
 buffer. (I don't think this is due to a recent change - I've been
 running into these lockups sporadically for several months.)

 The freezes are very difficult to replicate reliably. When they happen,
 emacs is unresponsive and can only be killed from the outside. Any tips
 on how to debug this would be greatly appreciated.

I also still experience semi-regular Emacs infloops, particularly when
editing clocking entries manually (with the arrow keys), in the LOGBOOK
drawer. It's quite often in such a situation, though not 100%
reproducible.

Unluckily, these infloops are not stoppable via C-g, as it seems to
occur in portions of code where quit is inhibited (see recent comments
from Stefan).

Current environment:

- GNU Emacs 24.4.50.1 (i686-pc-mingw32) of 2014-06-15 on LEG570

- Org-mode version 8.2.7 (release_8.2.7-1119-gfcc51c/) -- though I'll
  update right now!

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] still seeing semi-regular lockups

2014-06-25 Thread Daimrod
Matt Lundin m...@imapmail.org writes:

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 None of those three, I'm afraid! It was hanging on a variety of editing
 operations that, as far as I can tell, had little in common. There's a
 possibility that they were list-item-related, but really there wasn't
 much commonality.

 FYI, I recently fixed a bug[fn:1] that could introduce uncommon random
 lockups. Hopefully, it may be related to your problem (which is
 different from Daimrod's).

 Thanks for the followup! I was watching Daimrod's thread, and also
 Matt's most recent posting -- that also seemed more relevant to my
 problems, which were almost solely confined to log/state notes. I've
 pulled the fix, and will let you know if I see any more problems.

 With the latest git, I've experienced three lock-ups/freezes this
 evening when a) archiving a subtree to a file, b) changing a todo state
 with repeating timestamp, and 3) calling C-c C-c in an org-capture
 buffer. (I don't think this is due to a recent change - I've been
 running into these lockups sporadically for several months.)

 The freezes are very difficult to replicate reliably. When they happen,
 emacs is unresponsive and can only be killed from the outside. Any tips
 on how to debug this would be greatly appreciated.

See my previous post:
http://thread.gmane.org/gmane.emacs.orgmode/86255/focus=86263

You can wrap `jit-lock--debug-fontify' with:

(advice-add 'jit-lock--debug-fontify :around
(lambda (fun rest args)
  (with-local-quit (apply fun args

and then force emacs to break and display a backtrace by sending the
SIGUSR2 to the emacs process.

Best,

--
Daimrod/Greg



Re: [O] still seeing semi-regular lockups

2014-06-25 Thread Eric Abrahamsen
Daimrod daim...@gmail.com writes:

 Matt Lundin m...@imapmail.org writes:

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 None of those three, I'm afraid! It was hanging on a variety of editing
 operations that, as far as I can tell, had little in common. There's a
 possibility that they were list-item-related, but really there wasn't
 much commonality.

 FYI, I recently fixed a bug[fn:1] that could introduce uncommon random
 lockups. Hopefully, it may be related to your problem (which is
 different from Daimrod's).

 Thanks for the followup! I was watching Daimrod's thread, and also
 Matt's most recent posting -- that also seemed more relevant to my
 problems, which were almost solely confined to log/state notes. I've
 pulled the fix, and will let you know if I see any more problems.

 With the latest git, I've experienced three lock-ups/freezes this
 evening when a) archiving a subtree to a file, b) changing a todo state
 with repeating timestamp, and 3) calling C-c C-c in an org-capture
 buffer. (I don't think this is due to a recent change - I've been
 running into these lockups sporadically for several months.)

 The freezes are very difficult to replicate reliably. When they happen,
 emacs is unresponsive and can only be killed from the outside. Any tips
 on how to debug this would be greatly appreciated.

 See my previous post:
 http://thread.gmane.org/gmane.emacs.orgmode/86255/focus=86263

 You can wrap `jit-lock--debug-fontify' with:

 (advice-add 'jit-lock--debug-fontify :around
 (lambda (fun rest args)
   (with-local-quit (apply fun args

 and then force emacs to break and display a backtrace by sending the
 SIGUSR2 to the emacs process.

I think the advice here was also to run Org uncompiled, as that produces
a more useful backtrace, is that right? A couple of times I've gotten
SIGUSR2 to knock emacs out of a lock, but it was only while I was
running a compiled org. The one time I was running uncompiled and got a
lock, even SIGUSR2 couldn't bring it back...




Re: [O] still seeing semi-regular lockups

2014-06-25 Thread Bastien
Hi Eric,

Eric Abrahamsen e...@ericabrahamsen.net writes:

 I think the advice here was also to run Org uncompiled, as that produces
 a more useful backtrace, is that right?

Yes, that's right -- generally, backtraces from compiled Org are
mungled, while backtraces from an uncompiled Org are readable.

 A couple of times I've gotten
 SIGUSR2 to knock emacs out of a lock, but it was only while I was
 running a compiled org. The one time I was running uncompiled and got a
 lock, even SIGUSR2 couldn't bring it back...

Yes, compilation does not affect whether or not you can escape a lock.

-- 
 Bastien



Re: [O] still seeing semi-regular lockups

2014-06-25 Thread Eric Abrahamsen
Bastien b...@gnu.org writes:

 Hi Eric,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 I think the advice here was also to run Org uncompiled, as that produces
 a more useful backtrace, is that right?

 Yes, that's right -- generally, backtraces from compiled Org are
 mungled, while backtraces from an uncompiled Org are readable.

 A couple of times I've gotten
 SIGUSR2 to knock emacs out of a lock, but it was only while I was
 running a compiled org. The one time I was running uncompiled and got a
 lock, even SIGUSR2 couldn't bring it back...

 Yes, compilation does not affect whether or not you can escape a lock.

Right, I didn't mean to imply that, just that SIGUSR2 doesn't always
bring it back from the dead...




Re: [O] still seeing semi-regular lockups

2014-06-25 Thread Matt Lundin
Daimrod daim...@gmail.com writes:

 Matt Lundin m...@imapmail.org writes:


 The freezes are very difficult to replicate reliably. When they happen,
 emacs is unresponsive and can only be killed from the outside. Any tips
 on how to debug this would be greatly appreciated.

 See my previous post:
 http://thread.gmane.org/gmane.emacs.orgmode/86255/focus=86263

 You can wrap `jit-lock--debug-fontify' with:

 (advice-add 'jit-lock--debug-fontify :around
 (lambda (fun rest args)
   (with-local-quit (apply fun args

 and then force emacs to break and display a backtrace by sending the
 SIGUSR2 to the emacs process.


Thanks, that's helpful. It seems jit-lock--debug-fontify is the
development emacs. I'll build that in a moment...

For the record, I've been seeing these lockups with stable releases of
emacs (currently 24.3).

Thanks,
Matt



Re: [O] still seeing semi-regular lockups

2014-06-25 Thread Matt Lundin
Daimrod daim...@gmail.com writes:

 Matt Lundin m...@imapmail.org writes:

 With the latest git, I've experienced three lock-ups/freezes this
 evening when a) archiving a subtree to a file, b) changing a todo state
 with repeating timestamp, and 3) calling C-c C-c in an org-capture
 buffer. (I don't think this is due to a recent change - I've been
 running into these lockups sporadically for several months.)

 The freezes are very difficult to replicate reliably. When they happen,
 emacs is unresponsive and can only be killed from the outside. Any tips
 on how to debug this would be greatly appreciated.

 See my previous post:
 http://thread.gmane.org/gmane.emacs.orgmode/86255/focus=86263

 You can wrap `jit-lock--debug-fontify' with:

 (advice-add 'jit-lock--debug-fontify :around
 (lambda (fun rest args)
   (with-local-quit (apply fun args

 and then force emacs to break and display a backtrace by sending the
 SIGUSR2 to the emacs process.

O.K., I built the most emacs development from bzr and used the advice
above.

With killall -USR2 emacs, the following backtrace popped up, which
highlights flyspell as the culrpit. Note: I have flyspell turned on in
all text buffers, but I have (for several months) only experienced
lockups when using org-mode. I spend more time in TeX buffers than in
org-mode, and I have never had a lockup with AUCTeX.

--8---cut here---start-8---
* (setq quit-flag t)
  (condition-case nil (let ((inhibit-quit nil)) (let ((command
  this-command) deactivate-mark) (if (flyspell-check-pre-word-p)
  (save-excursion (quote (flyspell-debug-signal-pre-word-checked))
  (goto-char flyspell-pre-point) (flyspell-word))) (if
  (flyspell-check-word-p) (progn (quote
  (flyspell-debug-signal-word-checked)) (flyspell-word) (setq
  flyspell-pre-pre-buffer (current-buffer)) (setq flyspell-pre-pre-point
  (point))) (setq flyspell-pre-pre-buffer nil) (setq
  flyspell-pre-pre-point nil) (if (and (symbolp this-command) (get
  this-command (quote flyspell-delayed))) (progn (setq
  flyspell-word-cache-end -1) (setq flyspell-word-cache-result (quote
  _) (while (and (not (input-pending-p)) (consp flyspell-changes))
  (let ((start (car ...)) (stop (cdr ...))) (if
  (flyspell-check-changed-word-p start stop) (save-excursion (quote ...)
  (goto-char start) (flyspell-word))) (setq flyspell-changes (cdr
  flyspell-changes (setq flyspell-previous-command command))) (quit
  (setq quit-flag t) (eval (quote (ignore nil)
(progn (condition-case nil (let ((inhibit-quit nil)) (let ((command
this-command) deactivate-mark) (if (flyspell-check-pre-word-p)
(save-excursion (quote (flyspell-debug-signal-pre-word-checked))
(goto-char flyspell-pre-point) (flyspell-word))) (if
(flyspell-check-word-p) (progn (quote
(flyspell-debug-signal-word-checked)) (flyspell-word) (setq
flyspell-pre-pre-buffer (current-buffer)) (setq
flyspell-pre-pre-point (point))) (setq flyspell-pre-pre-buffer nil)
(setq flyspell-pre-pre-point nil) (if (and (symbolp this-command)
(get this-command ...)) (progn (setq flyspell-word-cache-end -1)
(setq flyspell-word-cache-result ... (while (and (not
(input-pending-p)) (consp flyspell-changes)) (let ((start ...) (stop
...)) (if (flyspell-check-changed-word-p start stop) (save-excursion
... ... ...)) (setq flyspell-changes (cdr flyspell-changes (setq
flyspell-previous-command command))) (quit (setq quit-flag t) (eval
(quote (ignore nil))
  (if flyspell-mode (progn (condition-case nil (let ((inhibit-quit
  nil)) (let ((command this-command) deactivate-mark) (if
  (flyspell-check-pre-word-p) (save-excursion (quote ...) (goto-char
  flyspell-pre-point) (flyspell-word))) (if (flyspell-check-word-p)
  (progn (quote ...) (flyspell-word) (setq flyspell-pre-pre-buffer
  ...) (setq flyspell-pre-pre-point ...)) (setq
  flyspell-pre-pre-buffer nil) (setq flyspell-pre-pre-point nil) (if
  (and ... ...) (progn ... ...))) (while (and (not ...) (consp
  flyspell-changes)) (let (... ...) (if ... ...) (setq
  flyspell-changes ...))) (setq flyspell-previous-command command)))
  (quit (setq quit-flag t) (eval (quote (ignore nil)))
flyspell-post-command-hook()
  recursive-edit()
--8---cut here---end---8---

Matt



Re: [O] still seeing semi-regular lockups

2014-06-25 Thread Matt Lundin
Matt Lundin m...@imapmail.org writes:

 With killall -USR2 emacs, the following backtrace popped up, which
 highlights flyspell as the culrpit.
 ~~~
And, of course, I had flyspell turned off when writing this email. :)

Matt



Re: [O] still seeing semi-regular lockups

2014-06-24 Thread Nicolas Goaziou
Hello,

Eric Abrahamsen e...@ericabrahamsen.net writes:

 None of those three, I'm afraid! It was hanging on a variety of editing
 operations that, as far as I can tell, had little in common. There's a
 possibility that they were list-item-related, but really there wasn't
 much commonality.

FYI, I recently fixed a bug[fn:1] that could introduce uncommon random
lockups. Hopefully, it may be related to your problem (which is
different from Daimrod's).


Regards,

[fn:1] 77e234e5785f5aaa60f1e316863a2571de64bbd4

-- 
Nicolas Goaziou



Re: [O] still seeing semi-regular lockups

2014-06-24 Thread Eric Abrahamsen
Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 None of those three, I'm afraid! It was hanging on a variety of editing
 operations that, as far as I can tell, had little in common. There's a
 possibility that they were list-item-related, but really there wasn't
 much commonality.

 FYI, I recently fixed a bug[fn:1] that could introduce uncommon random
 lockups. Hopefully, it may be related to your problem (which is
 different from Daimrod's).

Thanks for the followup! I was watching Daimrod's thread, and also
Matt's most recent posting -- that also seemed more relevant to my
problems, which were almost solely confined to log/state notes. I've
pulled the fix, and will let you know if I see any more problems.

Thanks
Eric




Re: [O] still seeing semi-regular lockups

2014-06-24 Thread Matt Lundin
Eric Abrahamsen e...@ericabrahamsen.net writes:

 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 None of those three, I'm afraid! It was hanging on a variety of editing
 operations that, as far as I can tell, had little in common. There's a
 possibility that they were list-item-related, but really there wasn't
 much commonality.

 FYI, I recently fixed a bug[fn:1] that could introduce uncommon random
 lockups. Hopefully, it may be related to your problem (which is
 different from Daimrod's).

 Thanks for the followup! I was watching Daimrod's thread, and also
 Matt's most recent posting -- that also seemed more relevant to my
 problems, which were almost solely confined to log/state notes. I've
 pulled the fix, and will let you know if I see any more problems.

With the latest git, I've experienced three lock-ups/freezes this
evening when a) archiving a subtree to a file, b) changing a todo state
with repeating timestamp, and 3) calling C-c C-c in an org-capture
buffer. (I don't think this is due to a recent change - I've been
running into these lockups sporadically for several months.)

The freezes are very difficult to replicate reliably. When they happen,
emacs is unresponsive and can only be killed from the outside. Any tips
on how to debug this would be greatly appreciated.

Matt



Re: [O] still seeing semi-regular lockups

2014-06-24 Thread Matt Lundin
Matt Lundin m...@imapmail.org writes:

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 None of those three, I'm afraid! It was hanging on a variety of editing
 operations that, as far as I can tell, had little in common. There's a
 possibility that they were list-item-related, but really there wasn't
 much commonality.

 FYI, I recently fixed a bug[fn:1] that could introduce uncommon random
 lockups. Hopefully, it may be related to your problem (which is
 different from Daimrod's).

 Thanks for the followup! I was watching Daimrod's thread, and also
 Matt's most recent posting -- that also seemed more relevant to my
 problems, which were almost solely confined to log/state notes. I've
 pulled the fix, and will let you know if I see any more problems.

 With the latest git, I've experienced three lock-ups/freezes this
 evening when a) archiving a subtree to a file, b) changing a todo state
 with repeating timestamp, and 3) calling C-c C-c in an org-capture
 buffer. (I don't think this is due to a recent change - I've been
 running into these lockups sporadically for several months.)

 The freezes are very difficult to replicate reliably. When they happen,
 emacs is unresponsive and can only be killed from the outside. Any tips
 on how to debug this would be greatly appreciated.

FWIW, Emacs just locked up again when I attempted to refile a subtree
from one org file to another (using org-refile).

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
Org-mode version beta_8.3 (beta_8.3-26-g1c3bdb @/home/user123/org-mode/lisp/)

Matt



Re: [O] still seeing semi-regular lockups

2014-06-22 Thread Nicolas Goaziou
Hello,

Daimrod daim...@gmail.com writes:

 Thanks for investigating.

I made some progress. Alas I didn't find a definitive answer yet.

The problem is related to `quail-input-method', which let-binds
`inhibit-modifications-hooks' to t. This is usually done around
a function that modifies text properties in a buffer.

However, in that case, it calls `quail-start-translation',
`quail-self-insert-command', `quail-self-insert-command' and eventually
`quail-update-translation', which modifies the _contents_ of the buffer
(twice actually, with `quail-delete-region' at line 1555 in
quail.el.gz and with `insert' at line 1579).

Since these modifications happen when `inhibit-modifications-hooks' is
non-nil, `after-change-functions' are never called, and the cache cannot
be updated properly, ending in a corrupted state.

There is a workaround for this: if `input-method-use-echo-area' is
non-nil, these modifications happen in the minibuffer, and, thus, the
buffer is not modified.

I also tried to set `inhibit-modifications-hooks' to nil around the two
locations where the buffer is modified (see above), but something odd
happens. Indeed, in that case, `after-change-functions' are called once
too many (i.e, the same buffer modification triggers these calls twice),
corrupting again the buffer. Unfortunately, I have no explanation about
this yet.


Regards,

-- 
Nicolas Goaziou



Re: [O] still seeing semi-regular lockups

2014-06-14 Thread Nicolas Goaziou
Daimrod daim...@gmail.com writes:

 My guess is that the lockup happens in `org-element--cache-key-less-p',
 called by `org-element--cache-process-request'.

Probably, but it doesn't mean that this particular function is buggy.
The lockup happens there because the cache gets corrupted at some point.

After investigating a little while, it appears that switching
input-method to latin-postfix alone is sufficient to corrupt it.
Though, setting `org-element-cache-sync-idle-time' to a high value
prevents the problem, which means that the corruption happens only when
cache is synchronized during idle time.

That's where I am for the time being. I don't know much about input
methods, so I have no clue about the reasons behind this. I'm still
investigating.


Regards,

-- 
Nicolas Goaziou



Re: [O] still seeing semi-regular lockups

2014-06-14 Thread Daimrod
Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Daimrod daim...@gmail.com writes:

 My guess is that the lockup happens in `org-element--cache-key-less-p',
 called by `org-element--cache-process-request'.

 Probably, but it doesn't mean that this particular function is buggy.
 The lockup happens there because the cache gets corrupted at some point.

I see.

 After investigating a little while, it appears that switching
 input-method to latin-postfix alone is sufficient to corrupt it.
 Though, setting `org-element-cache-sync-idle-time' to a high value
 prevents the problem, which means that the corruption happens only when
 cache is synchronized during idle time.

Ok.

 That's where I am for the time being. I don't know much about input
 methods, so I have no clue about the reasons behind this. I'm still
 investigating.

I would help if I knew about input-methods or the caching mechanism, but
I do not. :-(

Thanks for investigating.

Best,

-- 
Daimrod/Greg



Re: [O] still seeing semi-regular lockups

2014-06-11 Thread Daimrod
Daimrod daim...@gmail.com writes:

 Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 Daimrod daim...@gmail.com writes:

 I've attached part of the traces (the whole traces are way too big) and
 the backtraces.

 Thanks for looking into this. However, you are running a compiled Org,
 which renders backtraces less useful.

 Ok, I was wondering why the backtraces was so ugly, I didn't think about
 byte-compilation... Thanks for the tip.

 Also, you may want to disable cache refresh on idle time with, e.g.,

   (setq org-element-cache-sync-idle-time 3600)

 It could make the bug easier to reproduce.

 Thanks, I'll try again this w.e.

Okay, so I've found a more or less reliable way to reproduce this bug (on my
machine at least).

1. $ emacs -Q -l debug.el test.org
2. Expand headline (S-TAB)
3. go below the first headline (C-n)
4. press `i' a couple of seconds ~10 chars
5. delete the line (C-a C-k)
6. goto 4 until if locks up

As I said, it's not completely reliable but so far the lockup always
happens. Sometimes it happens after the third iteration, sometimes after
the tenth iteration, but it always happen.

I've attached `debug.el' and `test.org'.

`debug.el' setup the environment to reproduce the bug, you may need to
change the path to your orgmode source base and you'll need
`adaptive-wrap-prefix-mode' (available on ELPA).

I've been able to reproduce the bug without `adaptive-wrap-prefix-mode'
though other people have reported the same symptoms without using it.


`test.org' is a simple org file with two headlines. It seems that two
headlines are required to trigger the cache mechanism (with
`org-element-cache--sync').


Do you confirm the lockup with this setting?

Best,


* i

* i
i


debug.el
Description: application/emacs-lisp


-- 
Daimrod/Greg


Re: [O] still seeing semi-regular lockups

2014-06-11 Thread Nicolas Goaziou
Hello,

Daimrod daim...@gmail.com writes:

 Okay, so I've found a more or less reliable way to reproduce this bug (on my
 machine at least).

 1. $ emacs -Q -l debug.el test.org
 2. Expand headline (S-TAB)
 3. go below the first headline (C-n)
 4. press `i' a couple of seconds ~10 chars
 5. delete the line (C-a C-k)
 6. goto 4 until if locks up

 As I said, it's not completely reliable but so far the lockup always
 happens. Sometimes it happens after the third iteration, sometimes after
 the tenth iteration, but it always happen.

 I've attached `debug.el' and `test.org'.


[...]

 Do you confirm the lockup with this setting?

Yes, I do. I will investigate on this soon. Thank you for providing this
recipe.


Regards,

-- 
Nicolas Goaziou



Re: [O] still seeing semi-regular lockups

2014-06-11 Thread Daimrod
Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Daimrod daim...@gmail.com writes:

 Okay, so I've found a more or less reliable way to reproduce this bug (on my
 machine at least).

 1. $ emacs -Q -l debug.el test.org
 2. Expand headline (S-TAB)
 3. go below the first headline (C-n)
 4. press `i' a couple of seconds ~10 chars
 5. delete the line (C-a C-k)
 6. goto 4 until if locks up

 As I said, it's not completely reliable but so far the lockup always
 happens. Sometimes it happens after the third iteration, sometimes after
 the tenth iteration, but it always happen.

 I've attached `debug.el' and `test.org'.


 [...]

 Do you confirm the lockup with this setting?

 Yes, I do. I will investigate on this soon. Thank you for providing this
 recipe.

Cool!

Also, I should have mentioned that I didn't trace the function
`org-element--cache-key-less-p' because when I do so, Emacs stays locked
even when I send it the signal SIGUSR2. However, this function appears
in the backtrace produced by `xbacktrace' in a gdb session if I call it
during a lockup.

My guess is that the lockup happens in `org-element--cache-key-less-p',
called by `org-element--cache-process-request'.

Best,

-- 
Daimrod/Greg



Re: [O] still seeing semi-regular lockups

2014-06-04 Thread Daimrod
Eric Abrahamsen e...@ericabrahamsen.net writes:

 Daimrod daim...@gmail.com writes:

 Bastien b...@gnu.org writes:

 Hi Eric,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 After Nicolas made the last round of improvements to the caching
 mechanism I got far fewer hangs with Org, but they are still happening.
 Maybe once a day or so, on average, editing something in an Org buffer
 causes emacs to hang, and my fans to spin up, and there we are until I
 kill emacs.

 [...]

 By the way, if you want to see in which part the infloop occurs, you can
 attach a gdb debugger to the running emacs, source the
 path-to-emacs-source/src/.gdbinit file and use the `xbacktrace' command.

 $ gdb path-to-emacs-executable emacs-pid
 gdb) source path-to-emacs-source/src/.gdbinit
 ...
 gdb) xbacktrace

 You can also use the `bt' command but it contains much more noise.

 I got another one just now (while moving from one org table cell to the
 next), and that was the gdb backtrace:

 avl-tree--do-delete (0xbfffe858)
 avl-tree-delete (0xbfffe998)
 byte-code (0xbfffeaa0)
 byte-code (0xbfffec30)
 org-element--cache-process-request (0xbfffedd8)
 byte-code (0xbfffeef0)
 org-element--cache-sync (0xb0a8)
 org-element-at-point (0xb1e8)
 org-mode-flyspell-verify (0xb338)
 flyspell-word (0xb478)
 byte-code (0xb580)
 flyspell-post-command-hook (0xb784)

It seems the lockup also happens in `org-element--cache-...'.

 Not much, and probably not that useful. I'll start running org
 uncompiled, and try the debug-on-event trick.

Thanks for you time!

 FWIW, this was the first lockup that *didn't* occur in a logbook
 drawer -- that's where I usually get them. Either a full lockup, or else
 the cache goes wonky so that adding log notes (or even just navigating
 in the drawer) gives me that bound on wrong side of point you get when
 you try to search forwards, backwards.

That's weird (in my cases it usually mess up with the input-method).

-- 
Daimrod/Greg



Re: [O] still seeing semi-regular lockups

2014-05-30 Thread Nicolas Goaziou
Hello,

Daimrod daim...@gmail.com writes:

 I've attached part of the traces (the whole traces are way too big) and
 the backtraces.

Thanks for looking into this. However, you are running a compiled Org,
which renders backtraces less useful.

Also, you may want to disable cache refresh on idle time with, e.g.,

  (setq org-element-cache-sync-idle-time 3600)

It could make the bug easier to reproduce.


Regards,

-- 
Nicolas Goaziou



Re: [O] still seeing semi-regular lockups

2014-05-30 Thread Daimrod
Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 Daimrod daim...@gmail.com writes:

 I've attached part of the traces (the whole traces are way too big) and
 the backtraces.

 Thanks for looking into this. However, you are running a compiled Org,
 which renders backtraces less useful.

Ok, I was wondering why the backtraces was so ugly, I didn't think about
byte-compilation... Thanks for the tip.

 Also, you may want to disable cache refresh on idle time with, e.g.,

   (setq org-element-cache-sync-idle-time 3600)

 It could make the bug easier to reproduce.

Thanks, I'll try again this w.e.

Best,

-- 
Daimrod/Greg



Re: [O] still seeing semi-regular lockups

2014-05-20 Thread Eric Abrahamsen

On 05/19/14 23:21 PM, Daimrod wrote:
 Daimrod daim...@gmail.com writes:

 I have also semi-regular lockup with org-mode. I have opened a bug on
 debbugs and here is what Stefan told me to try to debug this:

 You can try `debug-on-event'.
 
 There's jit-lock-debug-mode but it doesn't disable inhibit-quit.
 So you'll need to additionally use
 
(advice-add 'jit-lock--debug-fontify :around
  (lambda (fun rest args)
(with-local-quit (apply fun args
 
 Of course sometimes this doesn't work because jit-lock-debug-mode
 changes the way things are executed and the bug may not manifest itself
 any more, but it's worth a try.
 
 Another source of info is to
 
   M-x trace-function RET org-adaptive-fill-function RET
   M-x trace-function RET org-element-at-point RET
   M-x trace-function RET org-element--cache-sync RET
   M-x trace-function RET org-element--cache-process-request RET
 
 Then reproduce the hang, then break the hang somehow (maybe with the
 jit-lock-debug hack above, or maybe with debug-on-event, or with C-g C-g
 C-g, ...), then look at the *trace..* buffer.

 I'll try to see what I can find this week end and report back.

 Ok, so the good news is the `debug-on-event' trick works. If you got a
 lockup, you can get a classic elisp backtrace by sending the SIGUSR2 to
 the Emacs process.

 The bad news is that I don't know yet how to reproduce the lockup. It
 seems to happen mostly (if not only) when I use org-mode +
 visual-line-mode + adaptive-wrap-prefix-mode + an input-method like
 latin-postfix.

 And it probably has to do with the cache mechanism. I'll try to
 reproduce it with the cache disabled but it hard to test because, as I
 said, I don't know how to reproduce it yet.

 I'll keep testing and see if I can reproduce it reliably.

 Stay tuned!

Of course I haven't gotten a single lock-up since reporting in last time...



Re: [O] still seeing semi-regular lockups

2014-05-20 Thread Daimrod
Eric Abrahamsen e...@ericabrahamsen.net writes:

 On 05/19/14 23:21 PM, Daimrod wrote:
 Daimrod daim...@gmail.com writes:

 I have also semi-regular lockup with org-mode. I have opened a bug on
 debbugs and here is what Stefan told me to try to debug this:

 You can try `debug-on-event'.
 
 There's jit-lock-debug-mode but it doesn't disable inhibit-quit.
 So you'll need to additionally use
 
(advice-add 'jit-lock--debug-fontify :around
  (lambda (fun rest args)
(with-local-quit (apply fun args
 
 Of course sometimes this doesn't work because jit-lock-debug-mode
 changes the way things are executed and the bug may not manifest itself
 any more, but it's worth a try.
 
 Another source of info is to
 
   M-x trace-function RET org-adaptive-fill-function RET
   M-x trace-function RET org-element-at-point RET
   M-x trace-function RET org-element--cache-sync RET
   M-x trace-function RET org-element--cache-process-request RET
 
 Then reproduce the hang, then break the hang somehow (maybe with the
 jit-lock-debug hack above, or maybe with debug-on-event, or with C-g C-g
 C-g, ...), then look at the *trace..* buffer.

 I'll try to see what I can find this week end and report back.

 Ok, so the good news is the `debug-on-event' trick works. If you got a
 lockup, you can get a classic elisp backtrace by sending the SIGUSR2 to
 the Emacs process.

 The bad news is that I don't know yet how to reproduce the lockup. It
 seems to happen mostly (if not only) when I use org-mode +
 visual-line-mode + adaptive-wrap-prefix-mode + an input-method like
 latin-postfix.

 And it probably has to do with the cache mechanism. I'll try to
 reproduce it with the cache disabled but it hard to test because, as I
 said, I don't know how to reproduce it yet.

 I'll keep testing and see if I can reproduce it reliably.

 Stay tuned!

 Of course I haven't gotten a single lock-up since reporting in last time...

:D

Do you have a similar setup? That is visual-line-mode,
adaptive-wrap-prefix-mode, input-method?

-- 
Daimrod/Greg



Re: [O] still seeing semi-regular lockups

2014-05-20 Thread Eric Abrahamsen
Daimrod daim...@gmail.com writes:

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 On 05/19/14 23:21 PM, Daimrod wrote:
 Daimrod daim...@gmail.com writes:

 I have also semi-regular lockup with org-mode. I have opened a bug on
 debbugs and here is what Stefan told me to try to debug this:

 You can try `debug-on-event'.
 
 There's jit-lock-debug-mode but it doesn't disable inhibit-quit.
 So you'll need to additionally use
 
(advice-add 'jit-lock--debug-fontify :around
  (lambda (fun rest args)
(with-local-quit (apply fun args
 
 Of course sometimes this doesn't work because jit-lock-debug-mode
 changes the way things are executed and the bug may not manifest itself
 any more, but it's worth a try.
 
 Another source of info is to
 
   M-x trace-function RET org-adaptive-fill-function RET
   M-x trace-function RET org-element-at-point RET
   M-x trace-function RET org-element--cache-sync RET
   M-x trace-function RET org-element--cache-process-request RET
 
 Then reproduce the hang, then break the hang somehow (maybe with the
 jit-lock-debug hack above, or maybe with debug-on-event, or with C-g C-g
 C-g, ...), then look at the *trace..* buffer.

 I'll try to see what I can find this week end and report back.

 Ok, so the good news is the `debug-on-event' trick works. If you got a
 lockup, you can get a classic elisp backtrace by sending the SIGUSR2 to
 the Emacs process.

 The bad news is that I don't know yet how to reproduce the lockup. It
 seems to happen mostly (if not only) when I use org-mode +
 visual-line-mode + adaptive-wrap-prefix-mode + an input-method like
 latin-postfix.

 And it probably has to do with the cache mechanism. I'll try to
 reproduce it with the cache disabled but it hard to test because, as I
 said, I don't know how to reproduce it yet.

 I'll keep testing and see if I can reproduce it reliably.

 Stay tuned!

 Of course I haven't gotten a single lock-up since reporting in last time...

 :D

 Do you have a similar setup? That is visual-line-mode,
 adaptive-wrap-prefix-mode, input-method?

None of those three, I'm afraid! It was hanging on a variety of editing
operations that, as far as I can tell, had little in common. There's a
possibility that they were list-item-related, but really there wasn't
much commonality.

E




Re: [O] still seeing semi-regular lockups

2014-05-19 Thread Daimrod
Daimrod daim...@gmail.com writes:

 I have also semi-regular lockup with org-mode. I have opened a bug on
 debbugs and here is what Stefan told me to try to debug this:

 You can try `debug-on-event'.
 
 There's jit-lock-debug-mode but it doesn't disable inhibit-quit.
 So you'll need to additionally use
 
(advice-add 'jit-lock--debug-fontify :around
  (lambda (fun rest args)
(with-local-quit (apply fun args
 
 Of course sometimes this doesn't work because jit-lock-debug-mode
 changes the way things are executed and the bug may not manifest itself
 any more, but it's worth a try.
 
 Another source of info is to
 
   M-x trace-function RET org-adaptive-fill-function RET
   M-x trace-function RET org-element-at-point RET
   M-x trace-function RET org-element--cache-sync RET
   M-x trace-function RET org-element--cache-process-request RET
 
 Then reproduce the hang, then break the hang somehow (maybe with the
 jit-lock-debug hack above, or maybe with debug-on-event, or with C-g C-g
 C-g, ...), then look at the *trace..* buffer.

 I'll try to see what I can find this week end and report back.

Ok, so the good news is the `debug-on-event' trick works. If you got a
lockup, you can get a classic elisp backtrace by sending the SIGUSR2 to
the Emacs process.

The bad news is that I don't know yet how to reproduce the lockup. It
seems to happen mostly (if not only) when I use org-mode +
visual-line-mode + adaptive-wrap-prefix-mode + an input-method like
latin-postfix.

And it probably has to do with the cache mechanism. I'll try to
reproduce it with the cache disabled but it hard to test because, as I
said, I don't know how to reproduce it yet.

I'll keep testing and see if I can reproduce it reliably.

Stay tuned!

-- 
Daimrod/Greg



Re: [O] still seeing semi-regular lockups

2014-05-15 Thread Bastien
Hi Eric,

Eric Abrahamsen e...@ericabrahamsen.net writes:

 After Nicolas made the last round of improvements to the caching
 mechanism I got far fewer hangs with Org, but they are still happening.
 Maybe once a day or so, on average, editing something in an Org buffer
 causes emacs to hang, and my fans to spin up, and there we are until I
 kill emacs.

I've seen hiccups here and there, but generally, what happens is an
error, not an infinite hanging.

 It happens often enough that I guess it's worth running emacs under some
 kind of debugger -- at least, I assume that's the best way of catching
 the bug. I'm not really sure how to go hunting, though, so if anyone had
 any advice in this direction, that would be great.

I'd hunt for some infloop in parsing -- but cannot detail more than
that, problably Nicolas could.

 In the meantime, is there any way of interrupting emacs so it quits
 whatever its doing, without having to kill it? I've played around with
 sending different signals using kill, just for fun, but everything
 I've tried either does nothing, or kills emacs altogether.

I have no suggestion here either, sorry :/

-- 
 Bastien



Re: [O] still seeing semi-regular lockups

2014-05-15 Thread Daimrod
Bastien b...@gnu.org writes:

 Hi Eric,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 After Nicolas made the last round of improvements to the caching
 mechanism I got far fewer hangs with Org, but they are still happening.
 Maybe once a day or so, on average, editing something in an Org buffer
 causes emacs to hang, and my fans to spin up, and there we are until I
 kill emacs.

 I've seen hiccups here and there, but generally, what happens is an
 error, not an infinite hanging.

 It happens often enough that I guess it's worth running emacs under some
 kind of debugger -- at least, I assume that's the best way of catching
 the bug. I'm not really sure how to go hunting, though, so if anyone had
 any advice in this direction, that would be great.

 I'd hunt for some infloop in parsing -- but cannot detail more than
 that, problably Nicolas could.

 In the meantime, is there any way of interrupting emacs so it quits
 whatever its doing, without having to kill it? I've played around with
 sending different signals using kill, just for fun, but everything
 I've tried either does nothing, or kills emacs altogether.

 I have no suggestion here either, sorry :/

I have also semi-regular lockup with org-mode. I have opened a bug on
debbugs and here is what Stefan told me to try to debug this:

 You can try `debug-on-event'.
 
 There's jit-lock-debug-mode but it doesn't disable inhibit-quit.
 So you'll need to additionally use
 
(advice-add 'jit-lock--debug-fontify :around
  (lambda (fun rest args)
(with-local-quit (apply fun args
 
 Of course sometimes this doesn't work because jit-lock-debug-mode
 changes the way things are executed and the bug may not manifest itself
 any more, but it's worth a try.
 
 Another source of info is to
 
   M-x trace-function RET org-adaptive-fill-function RET
   M-x trace-function RET org-element-at-point RET
   M-x trace-function RET org-element--cache-sync RET
   M-x trace-function RET org-element--cache-process-request RET
 
 Then reproduce the hang, then break the hang somehow (maybe with the
 jit-lock-debug hack above, or maybe with debug-on-event, or with C-g C-g
 C-g, ...), then look at the *trace..* buffer.

I'll try to see what I can find this week end and report back.

By the way, if you want to see in which part the infloop occurs, you can
attach a gdb debugger to the running emacs, source the
path-to-emacs-source/src/.gdbinit file and use the `xbacktrace' command.

$ gdb path-to-emacs-executable emacs-pid
gdb) source path-to-emacs-source/src/.gdbinit
...
gdb) xbacktrace

You can also use the `bt' command but it contains much more noise.

-- 
Daimrod/Greg


signature.asc
Description: PGP signature


Re: [O] still seeing semi-regular lockups

2014-05-15 Thread Bastien
Daimrod daim...@gmail.com writes:

 I'll try to see what I can find this week end and report back.

Great -- thanks for the guidance!

-- 
 Bastien



Re: [O] still seeing semi-regular lockups

2014-05-15 Thread Eric Abrahamsen
Daimrod daim...@gmail.com writes:

 Bastien b...@gnu.org writes:

 Hi Eric,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 After Nicolas made the last round of improvements to the caching
 mechanism I got far fewer hangs with Org, but they are still happening.
 Maybe once a day or so, on average, editing something in an Org buffer
 causes emacs to hang, and my fans to spin up, and there we are until I
 kill emacs.

[...]

 I have also semi-regular lockup with org-mode. I have opened a bug on
 debbugs and here is what Stefan told me to try to debug this:

 You can try `debug-on-event'.
 
 There's jit-lock-debug-mode but it doesn't disable inhibit-quit.
 So you'll need to additionally use
 
(advice-add 'jit-lock--debug-fontify :around
  (lambda (fun rest args)
(with-local-quit (apply fun args
 
 Of course sometimes this doesn't work because jit-lock-debug-mode
 changes the way things are executed and the bug may not manifest itself
 any more, but it's worth a try.
 
 Another source of info is to
 
   M-x trace-function RET org-adaptive-fill-function RET
   M-x trace-function RET org-element-at-point RET
   M-x trace-function RET org-element--cache-sync RET
   M-x trace-function RET org-element--cache-process-request RET
 
 Then reproduce the hang, then break the hang somehow (maybe with the
 jit-lock-debug hack above, or maybe with debug-on-event, or with C-g C-g
 C-g, ...), then look at the *trace..* buffer.

 I'll try to see what I can find this week end and report back.

 By the way, if you want to see in which part the infloop occurs, you can
 attach a gdb debugger to the running emacs, source the
 path-to-emacs-source/src/.gdbinit file and use the `xbacktrace' command.

 $ gdb path-to-emacs-executable emacs-pid
 gdb) source path-to-emacs-source/src/.gdbinit
 ...
 gdb) xbacktrace

 You can also use the `bt' command but it contains much more noise.

Thanks! This is the sort of thing I assumed I'd have to do, and it's
good to have an actual recipe. If you're on it, I might take the lazy
option and spectate for now... :)




Re: [O] still seeing semi-regular lockups

2014-05-15 Thread Daimrod
Eric Abrahamsen e...@ericabrahamsen.net writes:

 Daimrod daim...@gmail.com writes:

 Bastien b...@gnu.org writes:

 Hi Eric,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 After Nicolas made the last round of improvements to the caching
 mechanism I got far fewer hangs with Org, but they are still happening.
 Maybe once a day or so, on average, editing something in an Org buffer
 causes emacs to hang, and my fans to spin up, and there we are until I
 kill emacs.

 [...]

 I have also semi-regular lockup with org-mode. I have opened a bug on
 debbugs and here is what Stefan told me to try to debug this:

 You can try `debug-on-event'.
 
 There's jit-lock-debug-mode but it doesn't disable inhibit-quit.
 So you'll need to additionally use
 
(advice-add 'jit-lock--debug-fontify :around
  (lambda (fun rest args)
(with-local-quit (apply fun args
 
 Of course sometimes this doesn't work because jit-lock-debug-mode
 changes the way things are executed and the bug may not manifest itself
 any more, but it's worth a try.
 
 Another source of info is to
 
   M-x trace-function RET org-adaptive-fill-function RET
   M-x trace-function RET org-element-at-point RET
   M-x trace-function RET org-element--cache-sync RET
   M-x trace-function RET org-element--cache-process-request RET
 
 Then reproduce the hang, then break the hang somehow (maybe with the
 jit-lock-debug hack above, or maybe with debug-on-event, or with C-g C-g
 C-g, ...), then look at the *trace..* buffer.

 I'll try to see what I can find this week end and report back.

 By the way, if you want to see in which part the infloop occurs, you can
 attach a gdb debugger to the running emacs, source the
 path-to-emacs-source/src/.gdbinit file and use the `xbacktrace' command.

 $ gdb path-to-emacs-executable emacs-pid
 gdb) source path-to-emacs-source/src/.gdbinit
 ...
 gdb) xbacktrace

 You can also use the `bt' command but it contains much more noise.

 Thanks! This is the sort of thing I assumed I'd have to do, and it's
 good to have an actual recipe. If you're on it, I might take the lazy
 option and spectate for now... :)

No problem, but could you attach gdb during a lockup, source .gdbitinit
and use the `xbacktrace' command to see if the lockup happens at the
same place?

-- 
Daimrod/Greg



Re: [O] still seeing semi-regular lockups

2014-05-15 Thread Eric Abrahamsen
Daimrod daim...@gmail.com writes:

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 Daimrod daim...@gmail.com writes:

 Bastien b...@gnu.org writes:

 Hi Eric,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 After Nicolas made the last round of improvements to the caching
 mechanism I got far fewer hangs with Org, but they are still happening.
 Maybe once a day or so, on average, editing something in an Org buffer
 causes emacs to hang, and my fans to spin up, and there we are until I
 kill emacs.

 [...]

 I have also semi-regular lockup with org-mode. I have opened a bug on
 debbugs and here is what Stefan told me to try to debug this:

 You can try `debug-on-event'.
 
 There's jit-lock-debug-mode but it doesn't disable inhibit-quit.
 So you'll need to additionally use
 
(advice-add 'jit-lock--debug-fontify :around
  (lambda (fun rest args)
(with-local-quit (apply fun args
 
 Of course sometimes this doesn't work because jit-lock-debug-mode
 changes the way things are executed and the bug may not manifest itself
 any more, but it's worth a try.
 
 Another source of info is to
 
   M-x trace-function RET org-adaptive-fill-function RET
   M-x trace-function RET org-element-at-point RET
   M-x trace-function RET org-element--cache-sync RET
   M-x trace-function RET org-element--cache-process-request RET
 
 Then reproduce the hang, then break the hang somehow (maybe with the
 jit-lock-debug hack above, or maybe with debug-on-event, or with C-g C-g
 C-g, ...), then look at the *trace..* buffer.

 I'll try to see what I can find this week end and report back.

 By the way, if you want to see in which part the infloop occurs, you can
 attach a gdb debugger to the running emacs, source the
 path-to-emacs-source/src/.gdbinit file and use the `xbacktrace' command.

 $ gdb path-to-emacs-executable emacs-pid
 gdb) source path-to-emacs-source/src/.gdbinit
 ...
 gdb) xbacktrace

 You can also use the `bt' command but it contains much more noise.

 Thanks! This is the sort of thing I assumed I'd have to do, and it's
 good to have an actual recipe. If you're on it, I might take the lazy
 option and spectate for now... :)

 No problem, but could you attach gdb during a lockup, source .gdbitinit
 and use the `xbacktrace' command to see if the lockup happens at the
 same place?

Most definitely. Saving the instructions now...




[O] still seeing semi-regular lockups

2014-05-14 Thread Eric Abrahamsen
Hey there,

After Nicolas made the last round of improvements to the caching
mechanism I got far fewer hangs with Org, but they are still happening.
Maybe once a day or so, on average, editing something in an Org buffer
causes emacs to hang, and my fans to spin up, and there we are until I
kill emacs.

It happens often enough that I guess it's worth running emacs under some
kind of debugger -- at least, I assume that's the best way of catching
the bug. I'm not really sure how to go hunting, though, so if anyone had
any advice in this direction, that would be great.

In the meantime, is there any way of interrupting emacs so it quits
whatever its doing, without having to kill it? I've played around with
sending different signals using kill, just for fun, but everything
I've tried either does nothing, or kills emacs altogether.

Cheers,
Eric




Re: [O] still seeing semi-regular lockups

2014-05-14 Thread dieter
hi,

on my machine wanderlust hangs from time to time when i am inside the company 
net and
the proxy has hiccups.
then C-g (sometimes several) usually help.

in the link below i found an interesting variable, debug-on-quit.
when it is set, emacs enters the debugger when you hit C-g.

sendings signal to emacs from external usually only kills it.
the only signal which i am aware of that can be caught is SIGUSR1.
i used to use it to notify emacs about network changes.

hope this helps,
dieter

[1] 
http://www.gnu.org/software/emacs/manual/html_node/elisp/Infinite-Loops.html#Infinite-Loops



 Original Message 
From: Eric Abrahamsen e...@ericabrahamsen.net
To: emacs-orgmode@gnu.org
Sent: Wed, May 14, 2014, 10:36 AM
Subject: [O] still seeing semi-regular lockups

Hey there,

After Nicolas made the last round of improvements to the caching
mechanism I got far fewer hangs with Org, but they are still happening.
Maybe once a day or so, on average, editing something in an Org buffer
causes emacs to hang, and my fans to spin up, and there we are until I
kill emacs.

It happens often enough that I guess it's worth running emacs under some
kind of debugger -- at least, I assume that's the best way of catching
the bug. I'm not really sure how to go hunting, though, so if anyone had
any advice in this direction, that would be great.

In the meantime, is there any way of interrupting emacs so it quits
whatever its doing, without having to kill it? I've played around with
sending different signals using kill, just for fun, but everything
I've tried either does nothing, or kills emacs altogether.

Cheers,
Eric




Re: [O] still seeing semi-regular lockups

2014-05-14 Thread Eric Abrahamsen
die...@schoen.or.at writes:

 hi,

 on my machine wanderlust hangs from time to time when i am inside the company 
 net and
 the proxy has hiccups.
 then C-g (sometimes several) usually help.

 in the link below i found an interesting variable, debug-on-quit.
 when it is set, emacs enters the debugger when you hit C-g.

Whatever's going on here isn't network-related, it's pretty clearly
triggered by making editing changes to an org buffer. It's also
unsalvageable with C-g, or this whole thing would be much simpler!
There's an ongoing thread between Daimrod and Stephen that might
actually be the same issue, I'll check that out.

 sendings signal to emacs from external usually only kills it.
 the only signal which i am aware of that can be caught is SIGUSR1.
 i used to use it to notify emacs about network changes.

Good to know, thanks!

 hope this helps,
 dieter

 [1] 
 http://www.gnu.org/software/emacs/manual/html_node/elisp/Infinite-Loops.html#Infinite-Loops



 Original Message 
From: Eric Abrahamsen e...@ericabrahamsen.net
To: emacs-orgmode@gnu.org
Sent: Wed, May 14, 2014, 10:36 AM
Subject: [O] still seeing semi-regular lockups

Hey there,

After Nicolas made the last round of improvements to the caching
mechanism I got far fewer hangs with Org, but they are still happening.
Maybe once a day or so, on average, editing something in an Org buffer
causes emacs to hang, and my fans to spin up, and there we are until I
kill emacs.

It happens often enough that I guess it's worth running emacs under some
kind of debugger -- at least, I assume that's the best way of catching
the bug. I'm not really sure how to go hunting, though, so if anyone had
any advice in this direction, that would be great.

In the meantime, is there any way of interrupting emacs so it quits
whatever its doing, without having to kill it? I've played around with
sending different signals using kill, just for fun, but everything
I've tried either does nothing, or kills emacs altogether.

Cheers,
Eric