On Wed, Sep 2, 2009 at 7:57 PM, Stephen J. Turnbull<stephen(a)xemacs.org> wrote:
I've never been able to figure that stuff out. :-(
However, a quick look shows that compute_menubar_data is *designed* to
return 0 in case of problems. So this isn't quite the case of "uh-oh,
trouble, let's make like the Uneasy Rider". It's a debugging assert,
really -- we want to preserve state as close to where the problem
happened as possible.
Unfortunately, I can't pinpoint where that abort got introduced (Ben's
abort->ABORT patch of 2005-01-24 in r2500 is what introduced that
line; the surrounding code comes from r428, which is a tag, r21-2-22
which would be late 1999...).
If there's a reasonable way to continue from there, now that we think
it can't happen, we should signal a Lisp error, not abort. I wonder
if there's a way to get at the information that call_trapping_problems
should provide for us, and display that.
Apparently, this is what menubar-msw.c is doing. All it took was one
look at Rodney's error message and I knew what was triggering the
problem. The menubar-x.c version was harder to diagnose.
Remember, the crashers are expected to be one-shot tests. :-)
Ha! By definition! Still, I'm working too hard. The body of
truncate-string-to-width doesn't matter at all. It is never executed.
It's the fact that it takes 4 parameters rather than 5 that matters.
So here's the final version, which I will commit shortly:
(defbug 12 current
"Crash when clicking on the menubar, triggered by a Lisp error due to a
version of truncate-string-to-width that does not take 5 parameters.
Fatal error: assertion failed, file menubar-x.c, line 579, ABORT()
#'(lambda (str end-column &optional start-column padding) str))
XEmacs-Beta mailing list