bug#7958: Unresponsive visual bell on OSX

bug#7958: Unresponsive visual bell on OSX

[Neil Conway]

I'm using Emacs 23.2 (from MacPorts) on OSX 10.6.6. My .emacs includes
"(setq visible-bell t)", but when I do something that causes the bell
to be triggered, Emacs becomes very unresponsive (sometimes hanging
for 3 or 4 seconds, usually (much) longer).

Steps to repro:
1. Set visual bell to true
2. Run Emacs in console mode; I've tested using Terminal.app and iTerm2
3. Open a reasonably-sized file (e.g., 10 lines) and scroll past the
end of the file, e.g., using C-v

Instead of a visual bell, emacs instead refuses to respond to user
input for a lengthy period of time. If I attach with gdb, a typical
call stack looks like:

#0  0x00007fff88c81fca in __semwait_signal ()
#1  0x00007fff88c81e59 in nanosleep ()
#2  0x0000000100544fe5 in napms ()
#3  0x00000001005494fb in delay_output ()
#4  0x0000000100549738 in tputs ()
#5  0x0000000100067007 in tty_ring_bell ()
#6  0x0000000100005ae5 in Fding ()
#7  0x00000001000f3713 in Feval ()
[...]

I can actually get emacs to operate normally by forcing the bottom few
stack frames to return via "ret".

If I remove (setq visual-bell t) from my .emacs, I don't see this behavior.

bug#7958: Unresponsive visual bell on OSX

[Jan Djärv]

I can't reproduce this, starting from -Q and evalling (setq visible-bell t) 
and making the bell ding.  This on trunk and the emacs-23 branch.

Can you reproduce this when starting with -Q?

	Jan D.

Neil Conway skrev 2011-02-02 05.39:
> I'm using Emacs 23.2 (from MacPorts) on OSX 10.6.6. My .emacs includes
> "(setq visible-bell t)", but when I do something that causes the bell
> to be triggered, Emacs becomes very unresponsive (sometimes hanging
> for 3 or 4 seconds, usually (much) longer).
>
> Steps to repro:
> 1. Set visual bell to true
> 2. Run Emacs in console mode; I've tested using Terminal.app and iTerm2
> 3. Open a reasonably-sized file (e.g., 10 lines) and scroll past the
> end of the file, e.g., using C-v
>
> Instead of a visual bell, emacs instead refuses to respond to user
> input for a lengthy period of time. If I attach with gdb, a typical
> call stack looks like:
>
> #0  0x00007fff88c81fca in __semwait_signal ()
> #1  0x00007fff88c81e59 in nanosleep ()
> #2  0x0000000100544fe5 in napms ()
> #3  0x00000001005494fb in delay_output ()
> #4  0x0000000100549738 in tputs ()
> #5  0x0000000100067007 in tty_ring_bell ()
> #6  0x0000000100005ae5 in Fding ()
> #7  0x00000001000f3713 in Feval ()
> [...]
>
> I can actually get emacs to operate normally by forcing the bottom few
> stack frames to return via "ret".
>
> If I remove (setq visual-bell t) from my .emacs, I don't see this behavior.
>
>

bug#7958: Unresponsive visual bell on OSX

[Lars Ingebrigtsen]

Jan Djärv <jan.h.d@swipnet.se> writes:

> I can't reproduce this, starting from -Q and evalling (setq
> visible-bell t) and making the bell ding.  This on trunk and the
> emacs-23 branch.
>
> Can you reproduce this when starting with -Q?

More information was requested three years ago, but no further progress
has been made, so I'm closing this bug report.  If this problem is still
present, please reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/