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
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
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)
main(int 1, char * * 0x01b46fd8, char * * 0x01b50900) line 2781
XEMACS! mainCRTStartup + 180 bytes
_start() line 169
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))
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))))
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.
I'm sometimes slow in getting around to reading my mail, so if you
want to reach me faster, call 520-661-6661.
for the hell I've been