[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: C-g does not interrupt lisp code (emacs 21)
From: |
Philippe Waroquiers |
Subject: |
Re: C-g does not interrupt lisp code (emacs 21) |
Date: |
Thu, 25 Oct 2001 13:12:32 +0200 (METDST) |
> > sigblock(0x2000) ......................................... = 8192
>
> (1)
> Hmhmhm, the code is a maze in this area...
>
> I think this has something to do with polling for input. In both 20
> and 21, a SIGALRM handler should be used for polling, i.e. looking for
> input while Emacs is doing something else (that's the alarm(2)/sigvec
> I guess in the trace of 20). In 21, the SIGALRM, which should call
> function poll_for_input, might have been blocked in (1), but I can't
> see where that is in the code. Is there a way to get more information
> out of the trace? Could you please add a printf to poll_for_input
> to verify that it is really not running?
poll_for_input is not called. After searching more in details, the problem
is in atimer.c. A call to UNBLOCK_ATIMERS gives (after pre-processing)
an empty line.
adding
hey sigunblock (8192);
hey BLOCK_ATIMERS;
hey UNBLOCK_ATIMERS;
gives:
hey ;
hey sigblock ((1L << (14-1))) ;
hey ;
(after pre-processing -P atimer.c).
C-g works with the following piece of code:
/* Insert the timer in the list of active atimers. */
schedule_atimer (t);
printf ("bef unblock_atimers %d\n ", sigblock (0));
UNBLOCK_ATIMERS;
printf ("after unblock_atimers %d\n ", sigblock (0));
sigsetmask (sigblock (0) & ~ 8192);
printf ("after local unblock %d\n ", sigblock (0));
It is not clear to me how to see in syssignal.h this sigunblock definition
should
come from.
If I can do something more, do not hesitate ....
MORE DETAILS (probably not needed to read them if above summary is clear)
-------------------------------------------------------------------------
Looking more in details where sigblock was called, I obtained the following
stack
trace (nb: this is already a modified atimer.c, see below):
Breakpoint 3, 0x7efb1cc0 in sigblock () from /usr/lib/libc.2
(gdb) bt
#0 0x7efb1cc0 in sigblock () from /usr/lib/libc.2
#1 0x2251cc in start_atimer (type=ATIMER_RELATIVE, time={tv_sec = 1,
tv_usec = 0}, fn=0x400d3eea <show_hourglass>, client_data=0x0)
at atimer.c:132
#2 0x108b8c in start_hourglass () at xfns.c:10351
#3 0x11f358 in command_loop_1 () at keyboard.c:1638
#4 0x1c2224 in internal_condition_case (bfun=0x400d40da
<command_loop_1>, handlers=269707460, hfun=0x400d40e2 <cmd_error>)
at eval.c:1267
#5 0x11d9ac in command_loop_2 () at keyboard.c:1245
#6 0x1c1b50 in internal_catch (tag=269659812, func=0x400d40ca
<command_loop_2>, arg=269585412) at eval.c:1030
#7 0x11d938 in command_loop () at keyboard.c:1224
#8 0x11d0fc in recursive_edit_1 () at keyboard.c:950
#9 0x11d300 in Frecursive_edit () at keyboard.c:1006
#10 0x11b54c in main (argc=3, argv=0x7eff45a4, envp=0x7eff45b4) at
emacs.c:1547
(gdb)
I tried then to step into the UNBLOCK_ATIMERS line in atimer.c (just before the
set_alarm in function start_atimer.
This line was ignored by gdb (as it is a comment).
I then modified the code to add tracing and I saw that the signal was still
blocked after the unblock_atimers.
So, it seems that one way or another, the UNBLOCK_ATIMERS results in no code.
The following code shows it :
/* Insert the timer in the list of active atimers. */
schedule_atimer (t);
printf ("bef unblock_atimers %d\n ", sigblock (0));
UNBLOCK_ATIMERS;
printf ("after unblock_atimers %d\n ", sigblock (0));
sigsetmask (sigblock (0) & ~ 8192);
printf ("after local unblock %d\n ", sigblock (0));
gives the following trace:
gull: ./emacs
bef unblock_atimers 8192
after unblock_atimers 8192
after local unblock 0
bef unblock_atimers 8192
after unblock_atimers 8192
after local unblock 0
bef unblock_atimers 8192
after unblock_atimers 8192
after local unblock 0
bef unblock_atimers 8192
after unblock_atimers 8192
after local unblock 0
bef unblock_atimers 8192
after unblock_atimers 8192
after local unblock 0
With the above change, the C-g is interrupting the (while t).
Here is the cc command launched by make emacs:
cc -c -Wp,-H200000 -D_BSD -I/tmp/emacs_home/emacs-21.1/xpm-3.4k
-Demacs -DHAVE_CONFIG_H -DUSE_LUCID -I. -I/tmp/emacs_home/emacs-21.1/src
-Wp,-H200000 -D_BSD -I/usr/include/X11R6 -I/usr/include/X11R6
-I/usr/include/X11R5 -I/usr/include/Motif1.2 -I/usr/contrib/X11R6/include
-I/usr/contrib/X11R5/include -g atimer.c
When adding -P to the cc commands, in the similar code area, I obtain:
schedule_atimer (t);
printf ("bef unblock_atimers %d\n ", sigblock (0));
;
printf ("after unblock_atimers %d\n ", sigblock (0));
sigsetmask (sigblock (0) & ~ 8192);
printf ("after local unblock %d\n ", sigblock (0));
So, the pre-processing supposed to give an unblock fails.
This is the sigunblock which gives empty because a direct insertion of
hey sigunblock (8192);
hey BLOCK_ATIMERS;
hey UNBLOCK_ATIMERS;
gives:
hey ;
hey sigblock ((1L << (14-1))) ;
hey ;
--
Philippe WAROQUIERS Eurocontrol - Central Flow Management Unit
philippe.waroquiers@eurocontrol.int Rue de la fusee, 96
Tel: +32 2 729 97 35 1130 Brussels
Fax: +32 2 729 90 22 Belgium
Re: C-g does not interrupt lisp code (emacs 21), Eli Zaretskii, 2001/10/24