On Tue, Jan 15, 2013 at 8:44 PM, Jerry James <james(a)xemacs.org&gt; wrote: The problem is that if there is an error in a menu descriptor, we don't recover from it gracefully. In this particular case, the ESS code is using an Emacs menu cascade keyword that we don't support (:visible), resulting in this backtrace: #0 throw_or_bomb_out_unsafe (tag=..., val=val＠entry=..., bomb_out_p=bomb_out_p＠entry=0, sig=..., data=...) at eval.c:1809 #1 0x00000000004a96f3 in throw_or_bomb_out (tag=..., val=..., bomb_out_p=bomb_out_p＠entry=0, sig=..., data=...) at eval.c:1865 #2 0x00000000004a975f in flagged_a_squirmer (error_conditions=..., data=..., opaque=...) at eval.c:5749 #3 0x00000000004a354a in Fsignal (error_symbol=..., data=...) at eval.c:2489 #4 0x00000000004a5bdb in signal_error_1 (data=..., sig=...) at eval.c:2613 #5 signal_error (type=..., reason=reason＠entry=0x6599a6 "Unknown menu cascade keyword", frob=...) at eval.c:2723 #6 0x00000000004a5d86 in invalid_argument ( reason=reason＠entry=0x6599a6 "Unknown menu cascade keyword", frob=..., frob＠entry=...) at eval.c:3086 #7 0x00000000005fdd0d in menu_item_descriptor_to_widget_value_1 (desc=..., menu_type=menu_type＠entry=0, deep_p=deep_p＠entry=0, filter_p=filter_p＠entry=0, depth=depth＠entry=1) at menubar-x.c:196 #8 0x00000000005fd7aa in menu_item_descriptor_to_widget_value_1 (desc=..., menu_type=<optimized out>, deep_p=0, filter_p=0, depth=25233120, depth＠entry=0) at menubar-x.c:303 #9 0x00000000005fdd5c in protected_menu_item_descriptor_to_widget_value_1 ( gack=0x7fffffff9c00) at menubar-x.c:351 #10 0x00000000004a08ef in call_trapping_problems_2 (opaque=..., opaque＠entry=...) at eval.c:5759 #11 0x00000000004a3cad in call_with_condition_handler ( handler=handler＠entry=0x4a9720 <flagged_a_squirmer>, handler_arg=..., fun=fun＠entry=0x4a08e0 <call_trapping_problems_2>, arg=...) at eval.c:2327 #12 0x00000000004a3cf9 in call_trapping_problems_1 (opaque=..., opaque＠entry=...) at eval.c:5765 #13 0x00000000004a1e2c in internal_catch (tag=..., func=func＠entry=0x4a3ce0 <call_trapping_problems_1>, arg=..., threw=threw＠entry=0x7fffffff9a7c, thrown_tag=thrown_tag＠entry=0x7fffffff9a90, backtrace_before_throw=backtrace_before_throw＠entry=0x7fffffff9aa0) at eval.c:1694 #14 0x00000000004a4766 in call_trapping_problems (warning_class=..., warning_string=warning_string＠entry=0x659808 "Error during menu construction", flags=3, flags＠entry=0, problem=problem＠entry=0x0, fun=fun＠entry=0x5fdd30 <protected_menu_item_descriptor_to_widget_value_1>, arg=arg＠entry=0x7fffffff9c00) at eval.c:6038 #15 0x00000000005fd202 in menu_item_descriptor_to_widget_value (desc=..., desc＠entry=..., menu_type=menu_type＠entry=0, deep_p=deep_p＠entry=0, filter_p=filter_p＠entry=0) at menubar-x.c:412 #16 0x00000000005fe200 in compute_menubar_data (menubar=menubar＠entry=..., deep_p=deep_p＠entry=0, f=0x1809c00) at menubar-x.c:531 #17 0x00000000005fe308 in set_frame_menubar (f=f＠entry=0x1809c00, deep_p=deep_p＠entry=0, first_time_p=first_time_p＠entry=0) at menubar-x.c:575 We successfully catch the throw, but don't actually display the error anywhere before we hit the assert in frame 17 and die. I think that assert is wrong. A null return doesn't necessarily mean that the XEmacs code itself has a bug, which is what an assert should be checking. It can also mean that there is a bug in the menu specification, and we should just refuse to show the menu and pop up an error buffer to notify the user of the problem. I wonder if it is as easy as changing this: assert (data && (data->next || data->contents)); to: if (!data || (!data->next && !data->contents)) return 0; I'll try that later and see how it works out. -- Jerry James http://www.jamezone.org/ _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta