CRASH: problem in event code; automating adding bugs and such to web site

I'd been experimenting with making commands to grep through all files in a directory, minus annoying ones such as backups and auto-saves and CVS merge files [those than begin with .#...] etc. These files generate a long grep command using find ........... | xargs grep -n ... or something like this. [yes, i just realized that igrep does something similar, and i'm going to look into it.] but ... this creates very long entries in the Tools->Grep submenu, which lists the ten most recent grep commands. Too long, in fact -- you get errors reported when you try to invoke an entry on the Grep submenu. Recently, I tried this by accident, and got a crash! The call stack looks like Fdiscard_input() line 2464 + 20 bytes Ffuncall(int 1, long * 0x0082f9cc) line 3528 + 49 bytes execute_optimized_program(const unsigned char * 0x01f69910, int 6, long * 0x01bf6110) line 746 + 16 bytes funcall_compiled_function(long 29571328, int 1, long * 0x0082fcbc) line 518 + 53 bytes Ffuncall(int 2, long * 0x0082fcb8) line 3563 + 17 bytes call1(long 28448940, long 35644440) line 4183 + 11 bytes cmd_error(long 35644440, long 28368900) line 195 + 15 bytes condition_case_1(long 28368996, long (long)* 0x010506a6 command_loop_1(long), long 28368900, long (long, long)* 0x010500c0 cmd_error(long, long), long 28368900) line 1634 + 11 bytes command_loop_3() line 256 + 35 bytes command_loop_2(long 28368900) line 269 internal_catch(long 28448988, long (long)* 0x01050210 command_loop_2(long), long 28368900, int * volatile 0x00000000) line 1317 + 7 bytes initial_command_loop(long 28368900) line 305 + 25 bytes STACK_TRACE_EYE_CATCHER(int 1, char * * 0x01b46fd8, char * * 0x01b50900, int 0) line 2348 main(int 1, char * * 0x01b46fd8, char * * 0x01b50900) line 2781 XEMACS! mainCRTStartup + 180 bytes _start() line 169 KERNEL32! 77e992a6() and if you look at Fdiscard_input(), where the crash is, the code looks like while (!NILP (command_event_queue) || event_stream_event_pending_p (1)) { /* This will take stuff off the command_event_queue, or read it from the event_stream, but it will not block. */ next_event_internal (event, 1); Vquit_flag = Qnil; /* Treat C-g as a user event (ignore it). It is vitally important that we reset Vquit_flag here. Otherwise, if we're reading from a TTY console, maybe_read_quit_event() will notice that C-g has been set and send us another C-g. That will cause us to get right back here, and read another C-g, ad infinitum ... */ /* If the event is a user event, ignore it. */ if (!command_event_p (event)) { /* Otherwise, chain the event onto our list of events not to ignore, and keep reading until the queue is empty. This does not mean that if a subprocess is generating an infinite amount of output, we will never terminate (*provided* that the behavior of next_event_cb() is correct -- see the comment in events.h), because this loop ends as soon as there are no more user events on the command_event_queue or event_stream. */ enqueue_event (Fcopy_event (event, Qnil), &head, &tail); } } if (!NILP (command_event_queue) || !NILP (command_event_queue_tail)) abort (); the abort in the last line is where the crash happens. command_event_queue is not nil; rather, it is #<misc-user-event (eval (progn (require (quote compile)) (let ((grep-command (co ns (concat grep-command " *.[chCH]") (length grep-command)))) (call-interactivel y (quote grep)))))> which is exactly the command i invoked that caused the crashing. [I invoked it quickly, using `M-t g c'.] Now looking at the code, and given that it got to where it got, only one thing could have happened: in the while() condition, the command_event_queue was indeed empty, but then the call to event_stream_event_pending_p (1) puts an event onto the command_event_queue. Now I don't understand how the misc-user event that was already invoked and processed is getting seen again, but clearly something is amiss in this code. since this twisty windy code was reworked a lot for windows and i don't yet understand it, could some windows expert help? Stephen, could you file this away on your bug list somewhere? In general, is there an established procedure for adding entries to the list? Perhaps you have to add them, but maybe there could be something on the xemacs web site where you can submit a bug, feature request, etc. into the queue that awaits being processed? There should also be a way of displaying all the "unsorted" items -- i.e. submitted, not yet manually processed. i also gather there's some sort of XEmacs bug list already that's rotting out there, and some automatic scheme for adding to it? it's maybe on some weird server somewhere, once maintained by kyle? could the web maintainers maybe combine the two together into one service on www.xemacs.org? if so, i'll volunteer some time going through the bugs and assigning them priority and difficulty values and figuring out who most likely should be responsible for fixing the problem. -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through.