GNU bug report logs -
#31274
27.0.50; xdisp.c:7575: Emacs fatal error: assertion failed: IT_BYTEPOS (*it) == CHAR_TO_BYTE (IT_CHARPOS (*it))
Previous Next
Reported by: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Date: Thu, 26 Apr 2018 19:56:01 UTC
Severity: normal
Tags: moreinfo, unreproducible
Found in version 27.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 31274 in the body.
You can then email your comments to 31274 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31274
; Package
emacs
.
(Thu, 26 Apr 2018 19:56:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Monnier <monnier <at> IRO.UMontreal.CA>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 26 Apr 2018 19:56:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Package: Emacs
Version: 27.0.50
I can reproduce the above assertion failure when I do the following:
% src/emacs -Q /usr/bin/perl -l .../elpa/packages/nhexl-mode/nhexl-mode.el -f nhexl-mode --eval '(setq word-wrap t)'
y
M->
The `y` is because nhexl-mode prompts the user to convert the buffer
to unibyte and is not directly relevant: you can use find-file-literally
instead and the result is the same. I used /usr/bin/perl in the above
example, but I could reproduce the same crash with "any" binary
executable such as /bin/gzip and src/emacs (tho with some it doesn't
crash immediately).
Obviously, word-wrap in a binary buffer is not very meaningful, but
that doesn't justify a discrepancy between charpos and bytepos.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31274
; Package
emacs
.
(Sat, 28 Apr 2018 09:31:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 31274 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Date: Thu, 26 Apr 2018 15:54:55 -0400
>
> Package: Emacs
> Version: 27.0.50
>
> I can reproduce the above assertion failure when I do the following:
>
> % src/emacs -Q /usr/bin/perl -l .../elpa/packages/nhexl-mode/nhexl-mode.el -f nhexl-mode --eval '(setq word-wrap t)'
> y
> M->
I cannot reproduce this, with today's master of Emacs and of ELPA. I
tried on GNU/Linux (in -nw) and on MS-Windows (in a GUI session), and
both didn't trigger the assertion (tried with 3 executables, including
those you mentioned). I'm guessing some particular byte sequence
present in your binaries triggers this. So please provide more
details.
P.S. I frequently wonder why veteran experienced users omit crucial
information from their bug reports, such as the C backtrace in this
case, that is very easy for them to collect. Please don't ever assume
that something which is 100% reproducible on your system can be
similarly easily reproduced on any other system, and that therefore
those details are an unnecessary luxury.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31274
; Package
emacs
.
(Sat, 28 Apr 2018 09:49:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 31274 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 28 Apr 2018 12:29:47 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 31274 <at> debbugs.gnu.org
>
> I'm guessing some particular byte sequence present in your binaries
> triggers this.
Or maybe you have local changes that are responsible.
> P.S. I frequently wonder why veteran experienced users omit crucial
> information ^^^^^^^^^^^^^^^^^^^^^^^^^
Let alone veteran experienced developers.
Added tag(s) moreinfo and unreproducible.
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Fri, 04 May 2018 10:31:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31274
; Package
emacs
.
(Fri, 04 May 2018 10:36:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 31274 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
> I can reproduce the above assertion failure when I do the following:
>
> % src/emacs -Q /usr/bin/perl -l .../elpa/packages/nhexl-mode/nhexl-mode.el -f nhexl-mode --eval '(setq word-wrap t)'
> y
> M->
>
> The `y` is because nhexl-mode prompts the user to convert the buffer
> to unibyte and is not directly relevant: you can use find-file-literally
> instead and the result is the same.
I couldn't reproduce the assert failure, and I didn't get the unibyte
prompt either.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31274
; Package
emacs
.
(Fri, 04 May 2018 12:51:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 31274 <at> debbugs.gnu.org (full text, mbox):
> From: Noam Postavsky <npostavs <at> gmail.com>
> Date: Fri, 04 May 2018 06:35:22 -0400
> Cc: 31274 <at> debbugs.gnu.org
>
> > % src/emacs -Q /usr/bin/perl -l .../elpa/packages/nhexl-mode/nhexl-mode.el -f nhexl-mode --eval '(setq word-wrap t)'
> > y
> > M->
> >
> > The `y` is because nhexl-mode prompts the user to convert the buffer
> > to unibyte and is not directly relevant: you can use find-file-literally
> > instead and the result is the same.
>
> I couldn't reproduce the assert failure, and I didn't get the unibyte
> prompt either.
I think the unibyte prompt may or may not be seen, it depends on
whether Emacs succeeds to decide the file is a binary file, and uses
unibyte to begin with. And whether it decides that depends on the
contents of the file, so it could well be that you don't see it
(neither did I, FWIW).
Or maybe this is the sign of something special that happens on
Stefan's system, like local changes perhaps?
In any case, we need either a reproducer or a detailed backtrace to
make any progress with this bug.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31274
; Package
emacs
.
(Thu, 26 Sep 2019 19:30:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 31274 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> In any case, we need either a reproducer or a detailed backtrace to
> make any progress with this bug.
More information was requested, but no response was given within a
year, so I'm closing this bug report. If the problem still exists,
please reopen this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
31274 <at> debbugs.gnu.org and Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 26 Sep 2019 19:30:04 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 25 Oct 2019 11:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 265 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.