GNU bug report logs - #23917
25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out

Previous Next

Packages: emacs, org-mode;

Reported by: Robert Pluim <rpluim <at> gmail.com>

Date: Fri, 8 Jul 2016 12:43:02 UTC

Severity: normal

Tags: fixed

Found in version 25.0.95

Fixed in version 25.1

Done: npostavs <at> users.sourceforge.net

Bug is archived. No further changes may be made.

Full log


Message #8 received at 23917 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 23917 <at> debbugs.gnu.org
Subject: Re: bug#23917: 25.0.95;
 commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture
 to error out
Date: Fri, 08 Jul 2016 17:02:46 +0300
> From: Robert Pluim <rpluim <at> gmail.com>
> Date: Fri, 08 Jul 2016 14:42:02 +0200
> 
> (this is with org-20160704 from elpa. The org version ("8.2.10") in
> emacs-25 does not exhibit this error)
> 
> This is from emacs -Q, with a subsequent changing of load-paths to
> point at the elpa org. Reverting the commit mentioned above makes the
> error go away.
> 
> In gdb:
> 
> Breakpoint 3, Freplace_match (newtext=8699012, fixedcase=<optimised out>, literal=0, string=<optimised out>, subexp=<optimised out>)
>     at search.c:2710
> 2710	    error ("Match data clobbered by buffer modification hooks");
> (gdb) xbacktrace 
> "replace-match" (0xffffc680)
> "org-capture-empty-lines-after" (0xffffc850)
> "org-capture-place-entry" (0xffffca30)
> "org-capture-place-template" (0xffffcc10)
> "org-capture" (0xffffcf20)
> "funcall-interactively" (0xffffcf18)
> "call-interactively" (0xffffd180)
> "command-execute" (0xffffd328)
> "execute-extended-command" (0xffffd580)
> "funcall-interactively" (0xffffd578)
> "call-interactively" (0xffffd820)
> "command-execute" (0xffffd998)
> 
> Based on the discussion in Bug#23869, there's a hook somewhere that
> needs to do save-match-data

Right.

> but I have no idea how to figure out which one.

Run Emacs under a debugger, and set a breakpoint before the call to
replace_range in Freplace_match.  When the breakpoint breaks, make
sure it's indeed being called from org-capture-empty-lines-after, and
if so, do this:

  (gdb) watch -l search_regs.start[sub]
  (gdb) watch -l search_regs.end[sub]
  (gdb) watch -l search_regs.num_regs
  (gdb) continue

Then GDB will kick in as soon as one of these 3 is clobbered, and the
backtrace will show you whodunit.




This bug report was last modified 8 years and 303 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.