Crashes when frames are closed (21.5.10b)

I am asking a very broad question. I have turned in crash reports and won't bore the list with more of them. But I still have frame close crashes (latest CVS of Feb 12) in 21.5.10 on Mac OS X 10.2.3 running X11.app with xquartz window manager. I know there were reports earlier of other systems with similar crashes. Mine appear to be connected to code in either the function x_find_frame_for_window, Fdelete_frame, or one of the functions in the chain of commands between these two. The stack always ends with x_find_frame_for_window, and when I induce the crash, there is always a Fdelete_frame in there too. It does not occur when the program exits and deletes the only frame it owns. The error does not occur in 21.5.9b. I do not think it occurred in earlier versions of 21.5.10, but those had display errors instead. Has anyone else seen this crash? What suggestions could anyone give to help me isolate the code that is actually choking? It might be that some function is either returning a NULL pointer or referencing one. I think that the PPC may have the feature that references to address 0x00000000 cause BUS errors. It used to on the old 68000 series, and the register and stack show that something is trying to touch address 0x00000000 or run code at that address triggering Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 I am many years away from my fading knowledge of 68K assem errors and have no knowledge of PPC quirks, but this seems like a good guess and could explain why the crash does not show up with other architectures. By the way I have compiled the source with a number of configurations including the barest necessary to be able to create frames, but even the simplest form and starting with the -vanilla option crashes when I close a frame other than the one that opens at start up even if that frame is only a dialog box. The type of widgets, scrollbars, etc has no effect on the crash. Here is an exerpt from a typical stack frame: #0 0x002599e4 in x_find_frame_for_window #1 0x00259ae8 in x_any_widget_or_parent_to_frame #2 0x00259914 in x_any_window_to_frame #3 0x002541c8 in x_event_to_emacs_event #4 0x002585c8 in emacs_Xt_event_handler #5 0x9646ce18 in XtDispatchEventToWidget #6 0x9646d514 in DispatchEvent #7 0x9646d6a0 in _XtDefaultDispatcher #8 0x9646d968 in XtDispatchEvent #9 0x964774f4 in XtAppProcessEvent #10 0x0025879c in emacs_Xt_drain_queue #11 0x0008ee10 in event_stream_drain_queue #12 0x0008f280 in event_stream_quit_p #13 0x002046e0 in check_quit #14 0x0007b604 in unbind_to_hairy #15 0x0007b554 in unbind_to_1 #16 0x000659a8 in elisp_maphash #17 0x00105530 in check_window_subwindow_cache #18 0x00290780 in mark_window_as_deleted #19 0x0029ab28 in delete_all_subwindows #20 0x0029aaa0 in delete_all_subwindows #21 0x000f6150 in delete_frame_internal #22 0x000f6784 in Fdelete_frame I think #5-9 are OS or Library calls. I do not know how to get source-level debugging to work with gdb. I seem to remember when I used to work with GNU Emacs on the Atari many years ago, that I could see the source, so I assume I may just not be using the correct link flag to keep all the needed information. I would be happy to poke around to find which sections are causing this if I new the "magic" incantation. r. royar (who only teaches English for a living, which probably explains why he doesn't know what he's doing *8^) )