I've figured out the trigger! I setup a CentOS 7 VM and installed Emacs
26.2.90 and couldn't repro on it. So I compared all the environment
variables between Cygwin and the VM and performed some tests, and
discovered the issue is triggered by my "TERM" environment variable being
set to "xterm-256color".

I could reproduce on the clean VM using: TERM="xterm-256color" emacs -Q
test.cc

Launching Emacs in that way, and following the other steps given above,
should allow you to reproduce.

Best,
Jayden


On Sat, Jun 22, 2019 at 2:27 PM Jayden Navarro <jayden@yugabyte.com> wrote:

> Hi Alan,
>
> Yes, you are completely correct :-) Posted one thing but unintentionally
> took a "shortcut" when producing the backtrace (not a smart thing to do
> when trying to get people to repro...).
>
> Here's the backtrace when doing doing M-% foo <RET> bar <RET> (note that
> it's still 0, 1 not 0, 3!):
>
> Debugger entered--Lisp error: (args-out-of-range #<buffer test.cc> 0 1)
>   buffer-substring-no-properties(0 1)
>   perform-replace("foo" "bar" t nil nil nil nil nil nil nil nil)
>   query-replace("foo" "bar" nil nil nil nil nil)
>   funcall-interactively(query-replace "foo" "bar" nil nil nil nil nil)
>   call-interactively(query-replace nil nil)
>   command-execute(query-replace)
>
> Thank you for your help!
>
> Best,
> Jayden
>
>
> On Sat, Jun 22, 2019 at 1:50 PM Alan Mackenzie <acm@muc.de> wrote:
>
>> Hello again, Jayden.
>>
>> On Sat, Jun 22, 2019 at 07:25:30 -0700, Jayden Navarro wrote:
>> > Hello Alan,
>>
>> > Thank you for your response. Apologies for the ambiguous steps. Please
>> find
>> > more detailed information below:
>>
>> Thanks!
>>
>> > Here are the steps:
>>
>> > 1. Open a file in c++-mode (e.g. emacs -Q test.cc).
>>
>> > 2. Add 100 lines of some string (e.g. the word "bar" on every line for
>> 100
>> > lines, no quotes in the actual file):
>>
>> > bar
>> > bar
>> > bar
>> > bar
>> > ...
>> > bar
>>
>> > 3. Add a unique string to line 101 (e.g. the word "foo", no quotes in
>> the
>> > actual file).
>>
>> > bar
>> > bar
>> > bar
>> > bar
>> > ...
>> > bar
>> > foo
>> > <INCLUDE NEWLINE AT END OF FILE>
>>
>> > 4. Close Emacs
>>
>> > 5. Open up the file again: emacs -Q test.cc
>>
>> > 6. Replace the unique string with some other string: M-x query-replace
>> > <RET> foo <RET> bar <RET>
>>
>> Are you _sure_ that's what you typed?  ;-)
>>
>> > 7. You should hit: Args out of range: #<buffer test.cc>, 0, 1
>>
>> > Here's the backtrace when using debug-on-error:
>>
>> > Debugger entered--Lisp error: (args-out-of-range #<buffer test.cc> 0 1)
>> >   buffer-substring-no-properties(0 1)  <==============================
>> >   perform-replace("foo" "a" t nil nil nil nil nil nil nil nil)
>> >   query-replace("foo" "a" nil nil nil nil nil)
>> >   funcall-interactively(query-replace "foo" "a" nil nil nil nil nil)
>> >   call-interactively(query-replace nil nil)
>> >   command-execute(query-replace)
>>
>> There, it looks like you are trying to replace "foo" by "a".  I'm
>> interested in the (invalid) arguments 0, 1 passed to
>> buffer-substring-no-properties.  I suspect that these are derived from
>> the "match-data" for a string, in particular for the string "a".
>>
>> Could you please repeat the bug scenario, but this time try to replace
>> "foo" by "bar".  I predict you will then get the error message
>>
>>     (args-out-of-range #<buffer test.cc> 0 3)
>>
>> since the replacement string will then be 3 characters long.
>>
>> If that does indeed happen, it would be a very strong clue as to the
>> underlying bug.  Please try it as above, and post the backtrace here.
>> Thanks!
>>
>> [ .... ]
>>
>> > Here's the list of packages I have installed under $HOME/.emacs.d/elpa:
>>
>> > avy-0.3.0
>> > company-20181105.2312
>> > company-lean-20171102.1454
>> > dash-20180910.1856
>> > dash-functional-20180107.1618
>> > epl-20180205.2049
>> > f-20180106.922
>> > flycheck-20181127.1510
>> > gnupg
>> > go-mode-1.3.1
>> > haskell-mode-13.16
>> > lean-mode-20180906.1645
>> > pkg-info-20150517.1143
>> > rust-mode-20181008.1628
>> > s-20180406.808
>>
>> I think, I hope very strongly, that the -Q in emacs -Q will prevent any
>> packages being loaded.  Otherwise we have a problem in the Emacs core.
>>
>> > Best,
>> > Jayden
>>
>> --
>> Alan Mackenzie (Nuremberg, Germany).
>>
>