xasserts and vertical motion.

xasserts and vertical motion.

[David Kastrup]

There are now several xasserts in the vertical motion routines that
are supposed to check for some assumptions about progress made on
display.  I strongly recommend taking them out.

a) they are causing frequent aborts in normal editing operations.  At
a time where one has to refer people to the trunk Emacs for quite a
bit of functionality that feels somewhat unfortunate.

b) they don't check for _structural_ incoherence (namely that Emacs'
internal data structures are not garbled), but for _visual_
incoherence.  But for debugging this one needs information about what
kind of things happen on the screen at the time, and just in what
manner some expectations might get violated.  This is much easier to
get when Emacs remains operative and gets a chance to _display_ the
result of the operation instead of committing suicide.  After all, one
can then repeat the process and narrow down just what causes it.  And
it significantly widens the audience that can help with debugging.  It
is much easier to describe what happens on the screen than to pick
apart the data structures in an aborting Emacs (which are not usually
accessible with most compilers and the standard compiler flags for
optimization, anyway).

Those xasserts that replace visual cues with an aborting Emacs do not
just make using Emacs for serious work harder, but they also actively
_hinder_ debugging possibly occuring display problems.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: xasserts and vertical motion.

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> There are now several xasserts in the vertical motion routines that
> are supposed to check for some assumptions about progress made on
> display.  I strongly recommend taking them out.
>
> a) they are causing frequent aborts in normal editing operations.  At
> a time where one has to refer people to the trunk Emacs for quite a
> bit of functionality that feels somewhat unfortunate.

I think some of those xasserts are bogus -- it's just hard to _prove_.

In any case, I have removed two of them from move_it_vertically_backward
that are often triggered without any indication of anything actually
being wrong (emacs doesn't loop and the display looks fine).

> Those xasserts that replace visual cues with an aborting Emacs do not
> just make using Emacs for serious work harder, but they also actively
> _hinder_ debugging possibly occuring display problems.

I agree.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: xasserts and vertical motion.

[Richard Stallman]

    b) they don't check for _structural_ incoherence (namely that Emacs'
    internal data structures are not garbled), but for _visual_
    incoherence.  But for debugging this one needs information about what
    kind of things happen on the screen at the time, and just in what
    manner some expectations might get violated.  This is much easier to
    get when Emacs remains operative and gets a chance to _display_ the
    result of the operation instead of committing suicide.

You should be able to continue by typing the GDB `return' command
and then `c'.  Does it work?

Re: xasserts and vertical motion.

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     b) they don't check for _structural_ incoherence (namely that
>     Emacs' internal data structures are not garbled), but for
>     _visual_ incoherence.  But for debugging this one needs
>     information about what kind of things happen on the screen at
>     the time, and just in what manner some expectations might get
>     violated.  This is much easier to get when Emacs remains
>     operative and gets a chance to _display_ the result of the
>     operation instead of committing suicide.
>
> You should be able to continue by typing the GDB `return' command
> and then `c'.  Does it work?

Not really.  I think that "abort" may be marked as "noreturn" in the
GCC header files, and so GCC does not bother keeping the stack or code
in a consistent state after return.

As another consequence, without an explicit -fno-crossjumping placed
into CFLAGS, all asserts in a function will use the same call to
abort(), which means that the traceback from gdb will pick a random
(but usually fixed) assertion line in the source code as the
prospective culprit.

I'll mention that option in the debugging instructions if it is not
already there.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: xasserts and vertical motion.

[Richard Stallman]

    > You should be able to continue by typing the GDB `return' command
    > and then `c'.  Does it work?

    Not really.  I think that "abort" may be marked as "noreturn" in the
    GCC header files, and so GCC does not bother keeping the stack or code
    in a consistent state after return.

Perhaps you have to compile without optimization.

    As another consequence, without an explicit -fno-crossjumping placed
    into CFLAGS, all asserts in a function will use the same call to
    abort

That is another advantage to compiling without optimization.