How can I identify all changes to match-data?

Question

I have a sporadic error when running query-replace:

Args out of range: #<buffer lib.rs>, 0, 1

There are similar questions:

• Match data clobbered by buffer modification hooks
• (RegEx-)Replace: Sporadic Match data clobbered by buffer modification hooks

These point towards the problem being that something is overriding the match-data during the find-and-replace operation, but it's difficult to identify exactly what.

Is it possible to log to a buffer or enter the debugger any time that the match-data is modified? Is there another technique to identify what is clobbering the match-data, before I resort to line-by-line printf style debugging? Bisecting my init file would tell me what package I'm using is misbehaving, but not where the misbehavior occurs.

I've seen Tracking down a write to a variable, but that doesn't appear to apply to match-data, which is a function, not a variable. I've also seen How do I debug when match-data is not getting set?, which appears to be the opposite problem from mine.

Answer 1

Kudos for checking similar questions and their answers.

One thing you can do, to start with, is to set debug-on-error to t, to at least get a backtrace so you know which function raised the error, what function called it, etc. But that will only get you so far, probably.

There is no magic way I'm aware of to track down which code clobbers match data that you are hoping doesn't get clobbered.

1. Copy the overall code involved, so you have something you can modify without touching the original.

2. Insert calls to message at a few places (in your copy of the code), printing whatever info you're interested in (e.g. the match data).

3. Use the printed messages (in buffer *Messages*) to narrow down where the problem is, inserting more calls to message as needed (and perhaps removing calls no longer needed).

4. (Optional) After you've narrowed down the culprit to a function of interest, you might want to use debug-on-entry for that function, instead of continuing to insert message calls inside it. Use d to step through the debugger (or c to skip through a step without diving down into its code). Use e to evaluate a sexp at any time (e.g. (match-data ...)).

You can alternatively just start with #4, debugging from the beginning, if you at least have some idea of a high-level function where things go wrong.

Before using the debugger, load the source file that defines the function you want to step through. You can see better what's going on when you use the source code instead of byte-compiled code (.elc).