Jerry James writes:
On Mon, Aug 31, 2009 at 9:01 PM, Stephen J.
Turnbull<stephen(a)xemacs.org> wrote:
> However, there's also the question of how Lisp code can crash at all.
> Do you understand that mechanism?
The missing argument to the mule-util version of
truncate-string-to-width causes compute_menubar_data to return NULL
somehow. I still don't understand what's going on there. Then we
trigger the ABORT on line 579 of menubar-x.c.
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.
We don't have a minimal reproducer anymore, since I nuked the
offending version of truncate-string-to-width. I've tried to find
other ways to trigger this crash, so far without success. The only
way I know how to do it is to redefine truncate-string-to-width to the
mule-util version. Maybe it should be something like this (where I'm
using old-truncate-string-to-width to avoid affecting the other
tests)?
That's fine.
Remember, the crashers are expected to be one-shot tests. :-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta