Re: emacs21.2 freezes on hp when calling visible-bell

Re: emacs21.2 freezes on hp when calling visible-bell

[Eli Zaretskii]

On Wed, 20 Mar 2002, emacs wrote:

> If visible-bell is set to t, emacs freezes completely when the bell is
> invoked, for instance when typing C-g

Thank you for your report.

Can you run Emacs under a debugger and see where it gets stuck when you 
type C-g?  The file etc/DEBUG in the distribution gives some advice for 
debugging such problems.

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: <EMACS> Re: emacs21.2 freezes on hp when calling visible-bell

[Richard Stallman]

I am amazed that gettimeofday can hang.  I have no idea why.  Perhaps
you need to find an HP wizard for this.  Maybe Bruce Perens can help.

From: Maarten Vergauwen <Maarten.Vergauwen@esat.kuleuven.ac.be>
Date: Tue, 26 Mar 2002 11:50:38 +0100
To: rms@santafe.edu
Subject: Re: <EMACS> Re: emacs21.2 freezes on hp when calling visible-bell
In-Reply-To: <200203221226.NAA05825@barbar.esat.kuleuven.ac.be>

Richard Stallman writes:
 >     This happens only on hp, using X and only for 21.2. No problems
 >     encountered for 21.1 on hp, nor for 21.2 on hp without X, nor for 21.2
 >     on SGI, linux-i386, alpha, solaris or ultrix with X.
 > 
 > Unfortunately that means I can't even try to debug it.
 > Can you please try to debug it?  etc/DEBUG gives some advice.

OK, here goes.

1. If emacs is run under gdb, it hangs when trying to "flash" the visible
   bell.
2. kill -TSTP pid in another shell
3. gdb tells me that it's hanging in gettimeofday()

(gdb) bt
#0  0x7f7aeac8 in gettimeofday () from /usr/lib/libc.2
#1  0x179948 in alarm_signal_handler (signo=14) at atimer.c:372
#2  <signal handler called>
#3  0x7f794384 in fwrite () from /usr/lib/libc.2
#4  0xd0158 in main (argc=2139029609, argv=0x7f7f061c, envp=0x8)
    at emacs.c:1547

4. I added lots of fprintf(stderr,...) stuff to the code in xterm.c
   (function XTflash) and in this way I could determine that emacs was
   hanging on the line that says: 
	    select (0, NULL, NULL, NULL, &timeout);
   A strange thing is that the loop with "select" is sometimes executed 1,
   2, 3	 times before it hangs at this line.

5. I reconfigured and recompiled emacs-21.1 on the same system, with the
   same compiler and here the problem doesn't occur.

I'm at a loss here. Could you tell me what else I could try to find the
source of the problem ?


kind regards,

Maarten


-- 
MAARTEN VERGAUWEN
K.U.Leuven - ESAT-PSI   tel: +32-16-32.10.64  fax: +32-16-32.17.23
Kasteelpark Arenberg 10	e-mail:Maarten.Vergauwen@esat.kuleuven.ac.be
B-3001 Heverlee         http://www.esat.kuleuven.ac.be/~vergauwe




_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: <EMACS> Re: emacs21.2 freezes on hp when calling visible-bell

[Bruce Perens]

> 4. I added lots of fprintf(stderr,...) stuff to the code in xterm.c
>    (function XTflash) and in this way I could determine that emacs was
>    hanging on the line that says: 
> 	    select (0, NULL, NULL, NULL, &timeout);

Select is being used to pause the process with finer granularity than
sleep(). On return, the contents of timeout are _undefined_. Print
timeout.tv_sec and timeout.tv_usec before the call and see if their value
is sensible. It probably gets clobbered after the first call (or the first
few) and sends you into a very long delay, thus the "hang".

Tell me if that's not it, and I'll find an HP-UX pro.

> I am amazed that gettimeofday can hang.

Since this is emacs run under gdb, it could be a ptrace bug.

	Thanks

	Bruce

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: <EMACS> Re: emacs21.2 freezes on hp when calling visible-bell

[Maarten Vergauwen]

Bruce Perens writes:
 > 
 > Select is being used to pause the process with finer granularity than
 > sleep(). On return, the contents of timeout are _undefined_. Print
 > timeout.tv_sec and timeout.tv_usec before the call and see if their value
 > is sensible. It probably gets clobbered after the first call (or the first
 > few) and sends you into a very long delay, thus the "hang".

I did this before posting the bug report but didn't include the printout in
my original mail:

first call:

(ask for current with gettimeofday)
current: 1017306217s 417857us
(wakeup is invariant)
wakeup:  1017306217s 567830us
(here current gets the value of wakeup - current)
current: 0s 149973us
(timeout is always set to 10000us)
timeout: 0s 10000us
select
return from select

second iteration:

current: 1017306217s 431843us
wakeup:  1017306217s 567830us
current: 0s 135987us
timeout: 0s 10000us
select
return from select

third iteration:

current: 1017306217s 451596us
wakeup:  1017306217s 567830us
current: 0s 116234us
timeout: 0s 10000us
select

emacs hangs

 > 
 > Since this is emacs run under gdb, it could be a ptrace bug.

This "hanging" happens both under gdb and just standalone. The number of
iterations is unpredictable.


Maarten

-- 
MAARTEN VERGAUWEN
K.U.Leuven - ESAT-PSI   tel: +32-16-32.10.64  fax: +32-16-32.17.23
Kasteelpark Arenberg 10	e-mail:Maarten.Vergauwen@esat.kuleuven.ac.be
B-3001 Heverlee         http://www.esat.kuleuven.ac.be/~vergauwe

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel