emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Infinite loop with org-log-done 'time?
@ 2014-07-17 18:48 Ethan
  2014-07-18  7:50 ` Nicolas Goaziou
  2014-07-19  3:22 ` Matt Lundin
  0 siblings, 2 replies; 5+ messages in thread
From: Ethan @ 2014-07-17 18:48 UTC (permalink / raw)
  To: emacs-orgmode


[-- Attachment #1.1: Type: text/plain, Size: 1260 bytes --]

Hi list,

I'm running org-mode from git (version "8.3beta"), and recently I started
to get hangs in org files. I can't characterize them completely; I have a
clear memory of causing something when I hit Enter to create a newline
before a heading. Today I managed to reproduce it reliably when I changed a
particular heading from DONE to TODO. When I trigger the hang, emacs's CPU
spikes to 100% and C-g doesn't stop emacs (it flashes to signal that it got
a quit, but doesn't actually quit). I've had to kill emacs, sometimes with
-9, and restart.

The bug has been tricky to track down. I can reproduce it reliably in one
particular file by switching DONE to TODO on one particular heading.
Changing DONE to TODO on another nearby heading doesn't seem to cause the
problem. For this reason, I don't have a minimal example.

It doesn't happen in org-mode in stock emacs. It also doesn't happen, even
with org-mode from git, if I disable my '(org-log-done 'time)
customization. I managed to get a backtrace using gdb (attached). I can
provide (off-list) the .org file that I used to induce the failure.

I haven't seen anyone else comment about this issue so I assume it's
something specific to my configuration. Has anyone else seen anything like
this?

Ethan

[-- Attachment #1.2: Type: text/html, Size: 1466 bytes --]

[-- Attachment #2: backtrace.txt --]
[-- Type: text/plain, Size: 12986 bytes --]

(gdb) thread apply all backtrace

Thread 4 (Thread 0x7fffe37ae700 (LWP 10101)):
#0  0x00007ffff1a6afbd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff5618fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff56190ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff5619129 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007ffff563df15 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007ffff1d4b182 in start_thread (arg=0x7fffe37ae700) at pthread_create.c:312
#6  0x00007ffff1a7830d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Lisp Backtrace:
"org-heading-components" (0xffffae80)
"org-element-headline-parser" (0xffffb130)
"org-element--current-element" (0xffffb310)
"byte-code" (0xffffb460)
"org-element--parse-to" (0xffffb800)
"byte-code" (0xffffb950)
"org-element--cache-process-request" (0xffffbcf0)
"byte-code" (0xffffbe40)
"org-element--cache-sync" (0xffffc1f0)
"org-element--cache-submit-request" (0xffffc3f0)
"org-element--cache-after-change" (0xffffc628)
"replace-match" (0xffffc880)
"byte-code" (0xffffc9d0)
"org-add-planning-info" (0xffffcd90)
"byte-code" (0xffffcef0)
"org-todo" (0xffffd308)
"call-interactively" (0xffffd4c8)

Thread 3 (Thread 0x7fffe94fe700 (LWP 10098)):
#0  0x00007ffff1a6afbd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff5618fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff561930a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff6378e16 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x00007ffff563df15 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007ffff1d4b182 in start_thread (arg=0x7fffe94fe700) at pthread_create.c:312
#6  0x00007ffff1a7830d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Lisp Backtrace:
"org-heading-components" (0xffffae80)
---Type <return> to continue, or q <return> to quit---
"org-element-headline-parser" (0xffffb130)
"org-element--current-element" (0xffffb310)
"byte-code" (0xffffb460)
"org-element--parse-to" (0xffffb800)
"byte-code" (0xffffb950)
"org-element--cache-process-request" (0xffffbcf0)
"byte-code" (0xffffbe40)
"org-element--cache-sync" (0xffffc1f0)
"org-element--cache-submit-request" (0xffffc3f0)
"org-element--cache-after-change" (0xffffc628)
"replace-match" (0xffffc880)
"byte-code" (0xffffc9d0)
"org-add-planning-info" (0xffffcd90)
"byte-code" (0xffffcef0)
"org-todo" (0xffffd308)
"call-interactively" (0xffffd4c8)

Thread 2 (Thread 0x7fffe9cff700 (LWP 10097)):
#0  0x00007ffff1a6afbd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff5618fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff56190ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fffe9d071ad in ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
#4  0x00007ffff563df15 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007ffff1d4b182 in start_thread (arg=0x7fffe9cff700) at pthread_create.c:312
#6  0x00007ffff1a7830d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Lisp Backtrace:
"org-heading-components" (0xffffae80)
"org-element-headline-parser" (0xffffb130)
"org-element--current-element" (0xffffb310)
"byte-code" (0xffffb460)
"org-element--parse-to" (0xffffb800)
"byte-code" (0xffffb950)
"org-element--cache-process-request" (0xffffbcf0)
"byte-code" (0xffffbe40)
"org-element--cache-sync" (0xffffc1f0)
"org-element--cache-submit-request" (0xffffc3f0)
"org-element--cache-after-change" (0xffffc628)
"replace-match" (0xffffc880)
"byte-code" (0xffffc9d0)
---Type <return> to continue, or q <return> to quit---
"org-add-planning-info" (0xffffcd90)
"byte-code" (0xffffcef0)
"org-todo" (0xffffd308)
"call-interactively" (0xffffd4c8)

Thread 1 (Thread 0x7ffff7fafa80 (LWP 10093)):
#0  0x0000000000586845 in exec_byte_code (bytestr=15760786, vector=0, maxdepth=41983692,
    args_template=4611686018430533632, nargs=4611686018695757824, args=0x7fffffffac80) at bytecode.c:1943
#1  0x000000000054fa0f in funcall_lambda (fun=41790853, nargs=nargs@entry=0,
    arg_vector=arg_vector@entry=0x7fffffffae80) at eval.c:3010
#2  0x000000000054fd1b in Ffuncall (nargs=1, args=0x7fffffffae78) at eval.c:2839
#3  0x000000000058494b in exec_byte_code (bytestr=15760786, vector=0, maxdepth=41983692,
    args_template=4611686018430533632, nargs=4611686018695757824, args=0x0) at bytecode.c:900
#4  0x000000000054fa0f in funcall_lambda (fun=42714373, nargs=nargs@entry=2,
    arg_vector=arg_vector@entry=0x7fffffffb130) at eval.c:3010
#5  0x000000000054fd1b in Ffuncall (nargs=3, args=0x7fffffffb128) at eval.c:2839
#6  0x000000000058494b in exec_byte_code (bytestr=15760786, vector=0, maxdepth=41983692,
    args_template=4611686018430533632, nargs=4611686018695757824, args=0x7fffffffb120) at bytecode.c:900
#7  0x000000000054fa0f in funcall_lambda (fun=42813413, nargs=nargs@entry=4,
    arg_vector=arg_vector@entry=0x7fffffffb310) at eval.c:3010
#8  0x000000000054fd1b in Ffuncall (nargs=5, args=0x7fffffffb308) at eval.c:2839
#9  0x000000000058494b in exec_byte_code (bytestr=15760786, vector=0, maxdepth=41983692,
    args_template=4611686018430533632, nargs=4611686018695757824, args=0x7fffffffb320) at bytecode.c:900
#10 0x000000000054f3c5 in eval_sub (form=form@entry=35662582) at eval.c:2149
#11 0x000000000054e2be in internal_catch (tag=<optimized out>, func=0x54ef00 <eval_sub>, arg=35662582)
    at eval.c:1060
#12 0x00000000005850d9 in exec_byte_code (bytestr=15760786, vector=0, maxdepth=41983692,
    args_template=4611686018430533632, nargs=4611686018695757824, args=0x7fffffffb638) at bytecode.c:1081
#13 0x000000000054fa0f in funcall_lambda (fun=42866709, nargs=nargs@entry=3,
    arg_vector=arg_vector@entry=0x7fffffffb800) at eval.c:3010
#14 0x000000000054fd1b in Ffuncall (nargs=4, args=0x7fffffffb7f8) at eval.c:2839
#15 0x000000000058494b in exec_byte_code (bytestr=15760786, vector=0, maxdepth=41983692,
    args_template=4611686018430533632, nargs=4611686018695757824, args=0x7fffffffb7f0) at bytecode.c:900
#16 0x000000000054f3c5 in eval_sub (form=form@entry=35663942) at eval.c:2149
#17 0x000000000054e2be in internal_catch (tag=<optimized out>, func=0x54ef00 <eval_sub>, arg=35663942)
    at eval.c:1060
#18 0x00000000005850d9 in exec_byte_code (bytestr=15760786, vector=0, maxdepth=41983692,
    args_template=4611686018430533632, nargs=4611686018695757824, args=0x7fffffffbb28) at bytecode.c:1081
#19 0x000000000054fa0f in funcall_lambda (fun=42866093, nargs=nargs@entry=5,
    arg_vector=arg_vector@entry=0x7fffffffbcf0) at eval.c:3010
---Type <return> to continue, or q <return> to quit---
#20 0x000000000054fd1b in Ffuncall (nargs=6, args=0x7fffffffbce8) at eval.c:2839
#21 0x000000000058494b in exec_byte_code (bytestr=15760786, vector=0, maxdepth=41983692,
    args_template=4611686018430533632, nargs=4611686018695757824, args=0x0) at bytecode.c:900
#22 0x000000000054f3c5 in eval_sub (form=form@entry=35664022) at eval.c:2149
#23 0x000000000054e2be in internal_catch (tag=<optimized out>, func=0x54ef00 <eval_sub>, arg=35664022)
    at eval.c:1060
#24 0x00000000005850d9 in exec_byte_code (bytestr=15760786, vector=0, maxdepth=41983692,
    args_template=4611686018430533632, nargs=4611686018695757824, args=0x7fffffffc018) at bytecode.c:1081
#25 0x000000000054fa0f in funcall_lambda (fun=42864877, nargs=nargs@entry=3,
    arg_vector=arg_vector@entry=0x7fffffffc1f0) at eval.c:3010
#26 0x000000000054fd1b in Ffuncall (nargs=4, args=0x7fffffffc1e8) at eval.c:2839
#27 0x000000000058494b in exec_byte_code (bytestr=15760786, vector=0, maxdepth=41983692,
    args_template=4611686018430533632, nargs=4611686018695757824, args=0x7fffffffc1f0) at bytecode.c:900
#28 0x000000000054fa0f in funcall_lambda (fun=42876621, nargs=nargs@entry=3,
    arg_vector=arg_vector@entry=0x7fffffffc3f0) at eval.c:3010
#29 0x000000000054fd1b in Ffuncall (nargs=4, args=0x7fffffffc3e8) at eval.c:2839
#30 0x000000000058494b in exec_byte_code (bytestr=15760786, vector=0, maxdepth=41983692,
    args_template=4611686018430533632, nargs=4611686018695757824, args=0x7fffffffc3f8) at bytecode.c:900
#31 0x000000000054fa0f in funcall_lambda (fun=42867117, nargs=nargs@entry=3,
    arg_vector=arg_vector@entry=0x7fffffffc628) at eval.c:3010
#32 0x000000000054fd1b in Ffuncall (nargs=4, args=0x7fffffffc620) at eval.c:2839
#33 0x000000000054ffa9 in funcall_nil (nargs=<optimized out>, args=<optimized out>) at eval.c:2324
#34 0x000000000054e8bd in run_hook_with_args (nargs=4, args=0x7fffffffc620, funcall=0x54ffa0 <funcall_nil>)
    at eval.c:2509
#35 0x000000000054ea0a in Frun_hook_with_args (nargs=<optimized out>, args=<optimized out>) at eval.c:2370
#36 0x000000000050607b in signal_after_change (charpos=83989, lendel=lendel@entry=30, lenins=0) at insdel.c:2058
#37 0x0000000000506dff in replace_range (from=83989, to=<optimized out>, new=new@entry=8602529,
    prepare=prepare@entry=true, inherit=inherit@entry=false, markers=markers@entry=true) at insdel.c:1427
#38 0x000000000051fa35 in Freplace_match (newtext=8602529, fixedcase=<optimized out>, literal=<optimized out>,
    string=<optimized out>, subexp=<optimized out>) at search.c:2644
#39 0x000000000054fe5e in Ffuncall (nargs=<optimized out>, args=<optimized out>) at eval.c:2794
#40 0x000000000058494b in exec_byte_code (bytestr=15760786, vector=0, maxdepth=41983692,
    args_template=4611686018430533632, nargs=4611686018695757824, args=0x7fffffffc870) at bytecode.c:900
#41 0x000000000054f3c5 in eval_sub (form=form@entry=34847478) at eval.c:2149
#42 0x000000000054e2be in internal_catch (tag=<optimized out>, func=0x54ef00 <eval_sub>, arg=34847478)
    at eval.c:1060
#43 0x00000000005850d9 in exec_byte_code (bytestr=15760786, vector=0, maxdepth=41983692,
    args_template=4611686018430533632, nargs=4611686018695757824, args=0x7fffffffcba8) at bytecode.c:1081
#44 0x000000000054fa0f in funcall_lambda (fun=41459845, nargs=nargs@entry=3,
    arg_vector=arg_vector@entry=0x7fffffffcd90) at eval.c:3010
---Type <return> to continue, or q <return> to quit---
#45 0x000000000054fd1b in Ffuncall (nargs=4, args=0x7fffffffcd88) at eval.c:2839
#46 0x000000000058494b in exec_byte_code (bytestr=15760786, vector=0, maxdepth=41983692,
    args_template=4611686018430533632, nargs=4611686018695757824, args=0x7fffffffcd80) at bytecode.c:900
#47 0x000000000054f3c5 in eval_sub (form=form@entry=34813574) at eval.c:2149
#48 0x000000000054e2be in internal_catch (tag=<optimized out>, func=0x54ef00 <eval_sub>, arg=34813574)
    at eval.c:1060
#49 0x00000000005850d9 in exec_byte_code (bytestr=15760786, vector=0, maxdepth=41983692,
    args_template=4611686018430533632, nargs=4611686018695757824, args=0x7fffffffd0c8) at bytecode.c:1081
#50 0x000000000054fa0f in funcall_lambda (fun=41615149, nargs=nargs@entry=1,
    arg_vector=arg_vector@entry=0x7fffffffd308) at eval.c:3010
#51 0x000000000054fd1b in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffd300) at eval.c:2839
#52 0x000000000054c4d8 in Fcall_interactively (function=<optimized out>, record_flag=<optimized out>,
    keys=<optimized out>) at callint.c:852
#53 0x000000000054fe8c in Ffuncall (nargs=nargs@entry=4, args=args@entry=0x7fffffffd4c0) at eval.c:2785
#54 0x00000000005517e4 in call3 (fn=<optimized out>, arg1=<optimized out>, arg2=<optimized out>,
    arg3=<optimized out>) at eval.c:2603
#55 0x00000000004df61d in Fcommand_execute (cmd=<optimized out>, record_flag=<optimized out>,
    keys=<optimized out>, special=<optimized out>) at keyboard.c:10241
#56 0x00000000004ebec9 in command_loop_1 () at keyboard.c:1587
#57 0x000000000054e3e3 in internal_condition_case (bfun=bfun@entry=0x4ebb30 <command_loop_1>, handlers=12176114,
    hfun=hfun@entry=0x4e20f0 <cmd_error>) at eval.c:1289
#58 0x00000000004dd3ce in command_loop_2 (ignore=ignore@entry=12124434) at keyboard.c:1168
#59 0x000000000054e2be in internal_catch (tag=<optimized out>, func=func@entry=0x4dd3b0 <command_loop_2>,
    arg=12124434) at eval.c:1060
#60 0x00000000004e1c17 in command_loop () at keyboard.c:1147
#61 recursive_edit_1 () at keyboard.c:779
#62 0x00000000004e1f14 in Frecursive_edit () at keyboard.c:843
#63 0x00000000004171d5 in main (argc=<optimized out>, argv=0x7fffffffdad8) at emacs.c:1528

Lisp Backtrace:
"org-heading-components" (0xffffae80)
"org-element-headline-parser" (0xffffb130)
"org-element--current-element" (0xffffb310)
"byte-code" (0xffffb460)
"org-element--parse-to" (0xffffb800)
"byte-code" (0xffffb950)
"org-element--cache-process-request" (0xffffbcf0)
"byte-code" (0xffffbe40)
"org-element--cache-sync" (0xffffc1f0)
"org-element--cache-submit-request" (0xffffc3f0)
---Type <return> to continue, or q <return> to quit---
"org-element--cache-after-change" (0xffffc628)
"replace-match" (0xffffc880)
"byte-code" (0xffffc9d0)
"org-add-planning-info" (0xffffcd90)
"byte-code" (0xffffcef0)
"org-todo" (0xffffd308)
"call-interactively" (0xffffd4c8)

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

* Re: Infinite loop with org-log-done 'time?
  2014-07-17 18:48 Infinite loop with org-log-done 'time? Ethan
@ 2014-07-18  7:50 ` Nicolas Goaziou
  2014-07-23 17:03   ` Ethan
  2014-07-19  3:22 ` Matt Lundin
  1 sibling, 1 reply; 5+ messages in thread
From: Nicolas Goaziou @ 2014-07-18  7:50 UTC (permalink / raw)
  To: Ethan; +Cc: emacs-orgmode

Hello,

Ethan <ethan.glasser.camp@gmail.com> writes:

> I'm running org-mode from git (version "8.3beta"), and recently I started
> to get hangs in org files.

First ensure you're using the latest Org revision. A lot of changes
happened between "release_8.3beta" tag and HEAD.

> The bug has been tricky to track down. I can reproduce it reliably in one
> particular file by switching DONE to TODO on one particular heading.
> Changing DONE to TODO on another nearby heading doesn't seem to cause the
> problem. For this reason, I don't have a minimal example.
>
> It doesn't happen in org-mode in stock emacs. It also doesn't happen, even
> with org-mode from git, if I disable my '(org-log-done 'time)
> customization. I managed to get a backtrace using gdb (attached). I can
> provide (off-list) the .org file that I used to induce the failure.

If you can reproduce the problem with an up-to-date Org, I'm interested
in the org file. You can also consider calling the function below first

  (defun ngz-scramble-contents ()
    "Copy current buffer, preserving structure but not contents.
  The copy is done in \"*Scrambled text*\" buffer.  The function
  assumes current major mode is `org-mode'."
    (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))))


Regards,

-- 
Nicolas Goaziou

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

* Re: Infinite loop with org-log-done 'time?
  2014-07-17 18:48 Infinite loop with org-log-done 'time? Ethan
  2014-07-18  7:50 ` Nicolas Goaziou
@ 2014-07-19  3:22 ` Matt Lundin
  1 sibling, 0 replies; 5+ messages in thread
From: Matt Lundin @ 2014-07-19  3:22 UTC (permalink / raw)
  To: Ethan; +Cc: emacs-orgmode

Ethan <ethan.glasser.camp@gmail.com> writes:

> I'm running org-mode from git (version "8.3beta"), and recently I
> started to get hangs in org files. I can't characterize them
> completely; I have a clear memory of causing something when I hit Enter
> to create a newline before a heading. Today I managed to reproduce it
> reliably when I changed a particular heading from DONE to TODO. When I
> trigger the hang, emacs's CPU spikes to 100% and C-g doesn't stop emacs
> (it flashes to signal that it got a quit, but doesn't actually quit).
> I've had to kill emacs, sometimes with -9, and restart.
>
> The bug has been tricky to track down. I can reproduce it reliably in
> one particular file by switching DONE to TODO on one particular
> heading. Changing DONE to TODO on another nearby heading doesn't seem
> to cause the problem. For this reason, I don't have a minimal example.
>
> It doesn't happen in org-mode in stock emacs. It also doesn't happen,
> even with org-mode from git, if I disable my '(org-log-done 'time)
> customization. I managed to get a backtrace using gdb (attached). I can
> provide (off-list) the .org file that I used to induce the failure.
>
> I haven't seen anyone else comment about this issue so I assume it's
> something specific to my configuration. Has anyone else seen anything
> like this

I experience this. In my case, it seems to involve some mysterious
combination of the element cache, clocking, and logging. The lockups are
disruptive enough that I have to set org-element-use-cache to nil ---
otherwise I experience 2 to 3 lockups per hour. The problem completely
disappears with the cache off.

Alas, the baroque complexity of my .emacs and the size of my org files
make it difficult to discover the precise cause.

I'll see if I can provide an ECM.

Matt

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

* Re: Infinite loop with org-log-done 'time?
  2014-07-18  7:50 ` Nicolas Goaziou
@ 2014-07-23 17:03   ` Ethan
  2014-07-23 17:06     ` Ethan
  0 siblings, 1 reply; 5+ messages in thread
From: Ethan @ 2014-07-23 17:03 UTC (permalink / raw)
  To: Ethan, emacs-orgmode

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

Sorry for the late reply. Thanks for the advice Nicolas. Today I tried to
reproduce it with the same file and couldn't. However, I have hit the bug
(whatever it is) without org-log-done 'time, so I guess that was a red
herring. I'll keep an eye on it.

Ethan



On Fri, Jul 18, 2014 at 3:50 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Ethan <ethan.glasser.camp@gmail.com> writes:
>
> > I'm running org-mode from git (version "8.3beta"), and recently I started
> > to get hangs in org files.
>
> First ensure you're using the latest Org revision. A lot of changes
> happened between "release_8.3beta" tag and HEAD.
>
> > The bug has been tricky to track down. I can reproduce it reliably in one
> > particular file by switching DONE to TODO on one particular heading.
> > Changing DONE to TODO on another nearby heading doesn't seem to cause the
> > problem. For this reason, I don't have a minimal example.
> >
> > It doesn't happen in org-mode in stock emacs. It also doesn't happen,
> even
> > with org-mode from git, if I disable my '(org-log-done 'time)
> > customization. I managed to get a backtrace using gdb (attached). I can
> > provide (off-list) the .org file that I used to induce the failure.
>
> If you can reproduce the problem with an up-to-date Org, I'm interested
> in the org file. You can also consider calling the function below first
>
>   (defun ngz-scramble-contents ()
>     "Copy current buffer, preserving structure but not contents.
>   The copy is done in \"*Scrambled text*\" buffer.  The function
>   assumes current major mode is `org-mode'."
>     (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))))
>
>
> Regards,
>
> --
> Nicolas Goaziou
>

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

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

* Re: Infinite loop with org-log-done 'time?
  2014-07-23 17:03   ` Ethan
@ 2014-07-23 17:06     ` Ethan
  0 siblings, 0 replies; 5+ messages in thread
From: Ethan @ 2014-07-23 17:06 UTC (permalink / raw)
  To: Ethan, emacs-orgmode

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

I just noticed that there was a commit
3c14db868574c97eff0eb0df7a72a618d5517292 that might have fixed it. The
linked bug report seems to sound very similar to what I experienced. Thanks!

http://permalink.gmane.org/gmane.emacs.orgmode/88673

Ethan



On Wed, Jul 23, 2014 at 1:03 PM, Ethan <ethan.glasser.camp@gmail.com> wrote:

> Sorry for the late reply. Thanks for the advice Nicolas. Today I tried to
> reproduce it with the same file and couldn't. However, I have hit the bug
> (whatever it is) without org-log-done 'time, so I guess that was a red
> herring. I'll keep an eye on it.
>
> Ethan
>
>
>
> On Fri, Jul 18, 2014 at 3:50 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr>
> wrote:
>
>> Hello,
>>
>> Ethan <ethan.glasser.camp@gmail.com> writes:
>>
>> > I'm running org-mode from git (version "8.3beta"), and recently I
>> started
>> > to get hangs in org files.
>>
>> First ensure you're using the latest Org revision. A lot of changes
>> happened between "release_8.3beta" tag and HEAD.
>>
>> > The bug has been tricky to track down. I can reproduce it reliably in
>> one
>> > particular file by switching DONE to TODO on one particular heading.
>> > Changing DONE to TODO on another nearby heading doesn't seem to cause
>> the
>> > problem. For this reason, I don't have a minimal example.
>> >
>> > It doesn't happen in org-mode in stock emacs. It also doesn't happen,
>> even
>> > with org-mode from git, if I disable my '(org-log-done 'time)
>> > customization. I managed to get a backtrace using gdb (attached). I can
>> > provide (off-list) the .org file that I used to induce the failure.
>>
>> If you can reproduce the problem with an up-to-date Org, I'm interested
>> in the org file. You can also consider calling the function below first
>>
>>   (defun ngz-scramble-contents ()
>>     "Copy current buffer, preserving structure but not contents.
>>   The copy is done in \"*Scrambled text*\" buffer.  The function
>>   assumes current major mode is `org-mode'."
>>     (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))))
>>
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou
>>
>
>

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

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

end of thread, other threads:[~2014-07-23 17:07 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-17 18:48 Infinite loop with org-log-done 'time? Ethan
2014-07-18  7:50 ` Nicolas Goaziou
2014-07-23 17:03   ` Ethan
2014-07-23 17:06     ` Ethan
2014-07-19  3:22 ` Matt Lundin

Code repositories for project(s) associated with this inbox:

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).