"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Aidan Kehoe writes:
> > If --without-assertions is *necessary*, I would guess that the same
> > error is normally caught by an assertion somewhere.
> It means a bug in the semantics of the assertion, then.
You're assuming that XEmacs gets past the assertion. I mean that the
assertion crashes XEmacs before we get to the unrecognized byte code
I do see very occasional assertions (various ones), but they always
correspond to unresolved bugs, what I can get from the debugger is
invariably unhelpful, and I've not be able to reproduce. So I've not
done much about them.
From Emacs DEBUG the following life-saving advice:
** When you are trying to analyze failed assertions, it will be
essential to compile Emacs either completely without optimizations or
at least (when using GCC) with the -fno-crossjumping option. Failure
to do so may make the compiler recycle the same abort call for all
assertions in a given function, rendering the stack backtrace useless
for identifying the specific failed assertion.
I have tried to convince gcclib developers _not_ to declare the abort
function as _noreturn_ since its sole function over exit(1) is to create
a core dump and/or let a break point be set, and this is utterly useless
if the compiler assumes that it can trash the stack and does not need to
retain a recognizable return address.
It is useless to try arguing with Drepper. abort does not return, so
the declaration is noreturn, period. No changes that would cause less
"optimization" to occur are to be done.
So if you want to debug anything using assertions, use -fno-crossjumping
when compiling, or your stack frame is a piece of junk by the time you
hit your breakpoint, and you'll likely waste days figuring out why an
assertion triggered at a code point that actually never got executed.
XEmacs-Beta mailing list