bug#5851: 24.0.50; first character after opening quote often gets eaten in CC modes

bug#5851: 24.0.50; first character after opening quote often gets eaten in CC modes

[Paul Pogonyshev]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug.  If you can, give
a recipe starting from `emacs -Q':

As can be seen from 'recent input' section below, I typed a string in
C++ mode like this:

    "{}

However, due to an error in the Lisp code (byte-code: Invalid search
bound (wrong side of point)), it ended up looking like this:

    "}

i.e. the very first character after the opening quote got eaten and
never inserted into the buffer.

This does not happen always, but often enough.  It has been happening
for quite some time now, i.e. it is not something introduced very
recently.

Paul

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/usr/local/share/emacs/24.0.50/etc/DEBUG.


In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.18.9)
 of 2010-04-04 on gonzo
Windowing system distributor `The X.Org Foundation', version 11.0.10706000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: C++/l

Minor modes in effect:
  which-function-mode: t
  show-paren-mode: t
  server-mode: t
  auto-image-file-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
a r & <backspace> * SPC d e l i m i t e r s . SPC <backspace> 
<backspace> , SPC C-e <down> <down> <left> <left> <left> 
<left> d e M-/ [ 0 ] C-M-k C-s C-s C-g <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <M-left> 
<M-right> <right> <right> <right> <right> C-M-k d e 
M-/ [ 1 ] <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <up> <up> <up> <up> <up> <up> <left> <left> 
<left> <left> M-/ [ 0 ] C-M-k <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <M-left> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <left> <left> 
C-M-k d e M-/ [ 1 ] C-x C-s C-s p r i n t _ r C-w C-s 
C-s C-s <M-right> <M-right> <end> <left> <left> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<C-left> <C-left> <C-left> <C-left> " [ ] " , SPC C-x 
C-s C-x C-f C-g C-x C-f s e t <return> <M-right> <M-right> 
<M-left> " { } " , SPC <tab> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> C-x C-s C-x C-f 
m a <right> <return> <down> C-SPC <C-down> C-w <C-down> 
<C-down> <C-down> <C-down> <C-down> <C-down> <C-down> 
<C-down> <C-down> <C-up> <C-up> <C-up> <up> <M-left> 
<M-left> <M-left> <M-left> " { } <S-backspace> { } 
" , SPC C-x C-s <M-S-f9> <f5> <f5> <M-left> <M-left> 
<M-left> <M-left> c o n s t SPC c h a r * SPC M-/ , 
SPC C-x C-s <M-S-f9> C-e <f5> <end> <M-left> <M-left> 
<M-left> <M-left> " { } " , SPC <M-S-f9> y <f5> <end> 
<M-left> <M-left> <M-left> <M-left> " { } M-x r e p 
o r <tab> <return>

Recent messages:
Wrote /home/paul/mct/tests/map.cpp
(No files need saving)
Compilation exited abnormally with code 2
Saving file /home/paul/mct/tests/common.hpp...
Wrote /home/paul/mct/tests/common.hpp
(No files need saving)
Compilation exited abnormally with code 2
Saving file /home/paul/mct/tests/map.cpp...
Wrote /home/paul/mct/tests/map.cpp
Compilation exited abnormally with code 2
byte-code: Invalid search bound (wrong side of point)

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr message sendmail rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader
emacsbug grep newcomment dabbrev multi-isearch vc-bzr sha1 hex-util
cc-mode cc-fonts easymenu cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs compile comint ring which-func imenu eldoc saveplace
paren server ido cus-start cus-load thumbs image-file dired regexp-opt
advice help-fns advice-preload tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd font-setting tool-bar dnd fontset
image fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev loaddefs button minibuffer faces cus-face files
text-properties overlay md5 base64 format env code-pages mule custom
widget hashtable-print-readable backquote make-network-process dbusbind
system-font-setting font-render-setting gtk x-toolkit x multi-tty emacs)

bug#5851: 24.0.50; first character after opening quote often gets eaten in CC modes

[Paul Pogonyshev]

FWIW the bug is still present.  I get this backtrace (2011-02-19
build):

    (error "Invalid search bound (wrong side of point)")
      signal(error ("Invalid search bound (wrong side of point)"))
      byte-code("\bb\210\302	@	A\"\207" [start err signal] 3)
      c-syntactic-re-search-forward("[;{}]" 8510 end)
      c-before-change-check-<>-operators(6462 6462)
      #[(fn) "\b	\n\"\207" [fn beg end] 3](c-before-change-check-<>-operators)
      mapc(#[(fn) "\b	\n\"\207" [fn beg end] 3] (c-extend-region-for-CPP c-before-change-check-<>-operators))
      c-before-change(6462 6462)
      self-insert-command(1)
      call-interactively(self-insert-command nil nil)

I cannot find a reliable way to reproduce, but it happens often
enough.  Apparently, buffers not touched in quite a while are more
prone.  I.e. open a C++ file and leave it alone for 5 minutes.  Then
switch to the buffer and type outside any string a double quote
following by any other character --- the second character will likely
get eaten with an error as above.  M-x toggle-debug-on-error helps
spotting it.

Paul

bug#5851: 24.0.50; first character after opening quote often gets eaten in CC modes

[npostavs]

Paul Pogonyshev <pogonyshev@gmx.net> writes:

> FWIW the bug is still present.  I get this backtrace (2011-02-19
> build):
>
>     (error "Invalid search bound (wrong side of point)")
>       signal(error ("Invalid search bound (wrong side of point)"))
>       byte-code("\bb\210\302	@	A\"\207" [start err signal] 3)
>       c-syntactic-re-search-forward("[;{}]" 8510 end)
>       c-before-change-check-<>-operators(6462 6462)
>       #[(fn) "\b	\n\"\207" [fn beg end] 3](c-before-change-check-<>-operators)
>       mapc(#[(fn) "\b	\n\"\207" [fn beg end] 3] (c-extend-region-for-CPP c-before-change-check-<>-operators))
>       c-before-change(6462 6462)
>       self-insert-command(1)
>       call-interactively(self-insert-command nil nil)
>
> I cannot find a reliable way to reproduce, but it happens often
> enough.  Apparently, buffers not touched in quite a while are more
> prone.  I.e. open a C++ file and leave it alone for 5 minutes.  Then
> switch to the buffer and type outside any string a double quote
> following by any other character --- the second character will likely
> get eaten with an error as above.  M-x toggle-debug-on-error helps
> spotting it.

Maybe this is fixed in master now, along with Bug#28850?  (the error
there is the same, though the backtrace is a bit different)

bug#5851: 24.0.50; first character after opening quote often gets eaten in CC modes

[Stefan Kangas]

npostavs@gmail.com writes:

> Paul Pogonyshev <pogonyshev@gmx.net> writes:
>
>> FWIW the bug is still present.  I get this backtrace (2011-02-19
>> build):
>>
>>     (error "Invalid search bound (wrong side of point)")
>>       signal(error ("Invalid search bound (wrong side of point)"))
>>       byte-code(" b\210\302    @    A\"\207" [start err signal] 3)
>>       c-syntactic-re-search-forward("[;{}]" 8510 end)
>>       c-before-change-check-<>-operators(6462 6462)
>>       #[(fn) "     \n\"\207" [fn beg end] 3](c-before-change-check-<>-operators)
>>       mapc(#[(fn) "     \n\"\207" [fn beg end] 3] (c-extend-region-for-CPP c-before-change-check-<>-operators))
>>       c-before-change(6462 6462)
>>       self-insert-command(1)
>>       call-interactively(self-insert-command nil nil)
>>
>> I cannot find a reliable way to reproduce, but it happens often
>> enough.  Apparently, buffers not touched in quite a while are more
>> prone.  I.e. open a C++ file and leave it alone for 5 minutes.  Then
>> switch to the buffer and type outside any string a double quote
>> following by any other character --- the second character will likely
>> get eaten with an error as above.  M-x toggle-debug-on-error helps
>> spotting it.
>
> Maybe this is fixed in master now, along with Bug#28850?  (the error
> there is the same, though the backtrace is a bit different)

Indeed, it looks like this has been fixed on master -- or at least I
can't reproduce it.  Alan, what do you think?

Best regards,
Stefan Kangas

bug#5851: 24.0.50; first character after opening quote often gets eaten in CC modes

[Stefan Kangas]

Stefan Kangas <stefan@marxist.se> writes:

> npostavs@gmail.com writes:
>
>> Paul Pogonyshev <pogonyshev@gmx.net> writes:
>>
>>> FWIW the bug is still present.  I get this backtrace (2011-02-19
>>> build):
>>>
>>>     (error "Invalid search bound (wrong side of point)")
>>>       signal(error ("Invalid search bound (wrong side of point)"))
>>>       byte-code(" b\210\302    @    A\"\207" [start err signal] 3)
>>>       c-syntactic-re-search-forward("[;{}]" 8510 end)
>>>       c-before-change-check-<>-operators(6462 6462)
>>>       #[(fn) "     \n\"\207" [fn beg end] 3](c-before-change-check-<>-operators)
>>>       mapc(#[(fn) "     \n\"\207" [fn beg end] 3] (c-extend-region-for-CPP c-before-change-check-<>-operators))
>>>       c-before-change(6462 6462)
>>>       self-insert-command(1)
>>>       call-interactively(self-insert-command nil nil)
>>>
>>> I cannot find a reliable way to reproduce, but it happens often
>>> enough.  Apparently, buffers not touched in quite a while are more
>>> prone.  I.e. open a C++ file and leave it alone for 5 minutes.  Then
>>> switch to the buffer and type outside any string a double quote
>>> following by any other character --- the second character will likely
>>> get eaten with an error as above.  M-x toggle-debug-on-error helps
>>> spotting it.
>>
>> Maybe this is fixed in master now, along with Bug#28850?  (the error
>> there is the same, though the backtrace is a bit different)
>
> Indeed, it looks like this has been fixed on master -- or at least I
> can't reproduce it.  Alan, what do you think?

No further comments within 6 weeks.  I'll give it a couple of more
weeks, and if no one objects within that time, I'll just assume that
this has indeed been fixed and close this bug report.

Meanwhile, if anyone has been seeing this issue, please try it on
current master to see if the issue persists, then report back your
findings.

Best regards,
Stefan Kangas

bug#5851: 24.0.50; first character after opening quote often gets eaten in CC modes

[Alan Mackenzie]

Hello, Stefan.

On Sun, Nov 24, 2019 at 00:42:12 +0100, Stefan Kangas wrote:
> Stefan Kangas <stefan@marxist.se> writes:

> > npostavs@gmail.com writes:

> >> Paul Pogonyshev <pogonyshev@gmx.net> writes:

> >>> FWIW the bug is still present.  I get this backtrace (2011-02-19
> >>> build):

> >>>     (error "Invalid search bound (wrong side of point)")
> >>>       signal(error ("Invalid search bound (wrong side of point)"))
> >>>       byte-code(" b\210\302    @    A\"\207" [start err signal] 3)
> >>>       c-syntactic-re-search-forward("[;{}]" 8510 end)
> >>>       c-before-change-check-<>-operators(6462 6462)
> >>>       #[(fn) "     \n\"\207" [fn beg end] 3](c-before-change-check-<>-operators)
> >>>       mapc(#[(fn) "     \n\"\207" [fn beg end] 3] (c-extend-region-for-CPP c-before-change-check-<>-operators))
> >>>       c-before-change(6462 6462)
> >>>       self-insert-command(1)
> >>>       call-interactively(self-insert-command nil nil)

> >>> I cannot find a reliable way to reproduce, but it happens often
> >>> enough.  Apparently, buffers not touched in quite a while are more
> >>> prone.  I.e. open a C++ file and leave it alone for 5 minutes.  Then
> >>> switch to the buffer and type outside any string a double quote
> >>> following by any other character --- the second character will likely
> >>> get eaten with an error as above.  M-x toggle-debug-on-error helps
> >>> spotting it.

> >> Maybe this is fixed in master now, along with Bug#28850?  (the error
> >> there is the same, though the backtrace is a bit different)

> > Indeed, it looks like this has been fixed on master -- or at least I
> > can't reproduce it.  Alan, what do you think?

> No further comments within 6 weeks.  I'll give it a couple of more
> weeks, and if no one objects within that time, I'll just assume that
> this has indeed been fixed and close this bug report.

I think the time has come to close the bug.  I think it highly likely
it's been fixed, probably quite some while ago.  There have been quite a
few bugs with similar symptoms over the years.

> Meanwhile, if anyone has been seeing this issue, please try it on
> current master to see if the issue persists, then report back your
> findings.

> Best regards,
> Stefan Kangas

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#5851: 24.0.50; first character after opening quote often gets eaten in CC modes

[Stefan Kangas]

Hi Alan,

Alan Mackenzie <acm@muc.de> writes:

>> No further comments within 6 weeks.  I'll give it a couple of more
>> weeks, and if no one objects within that time, I'll just assume that
>> this has indeed been fixed and close this bug report.
>
> I think the time has come to close the bug.  I think it highly likely
> it's been fixed, probably quite some while ago.  There have been quite a
> few bugs with similar symptoms over the years.

Thanks, I'm therefore closing the bug now.

Best regards,
Stefan Kangas