Bug#470882: /dev/gpmctl freezes acknowledge
clone 470882 -1
reassign -1 ncurses
retitle -1 ncurses should check the value returned by Gpm_GetEvent()
thanks
Gerfried Fuchs, le Sat 22 Nov 2008 17:44:07 +0100, a écrit :
Ah, right. And aptitude does behave false here too (last two lines from
strace):
write(2, Uncaught exception: Unable to read from stdin: Bad file
descriptor\n..., 67) = 67
exit_group(-1) = ?
I guess we need to clone the bug to there, too, or rather libncurses
through which it seems to use gpm, it doesn't directly depend on libgpm.
Ah, right, doing so with a patch.
Not sure what other applications might be affected by it and should get
addressed, too ...
Well, all the rdeps :/
Samuel
--- ncurses/base/lib_mouse.c.orig 2008-11-24 00:29:19.0 +0100
+++ ncurses/base/lib_mouse.c2008-11-24 00:31:12.0 +0100
@@ -651,7 +651,15 @@
/* query server for event, return TRUE if we find one */
Gpm_Event ev;
- if (my_Gpm_GetEvent(ev) == 1) {
+ if (sp-_mouse_fd == -1)
+ break;
+
+ switch (my_Gpm_GetEvent(ev)) {
+ case 0:
+ /* Connection closed, drop the mouse. */
+ sp-_mouse_fd = -1;
+ break;
+ case 1:
/* there's only one mouse... */
eventp-id = NORMAL_EVENT;
@@ -684,6 +692,7 @@
/* bump the next-free pointer into the circular list */
sp-_mouse_eventp = eventp = NEXT(eventp);
result = TRUE;
+ break;
}
}
break;
Bug#470882: /dev/gpmctl freezes acknowledge
clone 470882 -1 reassign -1 aalib tags -1 - patch retitle -1 aalib should check the value returned by Gpm_GetEvent() thanks Gerfried Fuchs, le Sat 22 Nov 2008 17:44:07 +0100, a écrit : Not sure what other applications might be affected by it and should get addressed, too ... aalib is affected too. Reading the documentation of Gpm_GetEvent: « It returns 1 on success, -1 on failure, and 0 after closing the connection. » aalib doesn't properly check that. It should and for instance call gpm_uninit in that case. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470882: /dev/gpmctl freezes acknowledge
* Samuel Thibault [EMAIL PROTECTED] [2008-11-12 19:33:19 CET]: It is: now you at least get a connexion, and get rejected. Hmm, alright. The pdmenu segfault is due to another bug, see my mail dated 11th October. Ah, right. And aptitude does behave false here too (last two lines from strace): write(2, Uncaught exception: Unable to read from stdin: Bad file descriptor\n..., 67) = 67 exit_group(-1) = ? I guess we need to clone the bug to there, too, or rather libncurses through which it seems to use gpm, it doesn't directly depend on libgpm. Not sure what other applications might be affected by it and should get addressed, too ... Thanks, Rhonda -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470882: /dev/gpmctl freezes acknowledge
* Samuel Thibault [EMAIL PROTECTED] [2008-11-11 22:24:53 CET]: The problem is that you both want a mouse on the text console and a mouse in X. The correct way is to use a repeater: gpm reads /dev/input/mice, and repeats to X. Now, gpm tries to play nice with X servers that would read /dev/input/mice themselves: if a repeater is not setup, then when not in text mode gpm closes the mouse (to let X open it). The unfortunate effect here is that it waits without handling clients. The attached patch fixes that: when not in text mode, the mouse is closed, but the select() loop continues. I had to change the timeout of select, I have made it 2 seconds, like the latency of the previously-used wait_text(). That should fix the hang of clients. Are you sure with that fix? I applied it and did a local rebuild, and now pdmenu segfaults on any keypress after starting. I don't really call that an improvment. :) Just to be sure I did it properly, I dumped your patch into debian/patches/060_eliminate-hang-in-X11 and added it to the series file, the rebuild did happen in a current sid chroot. So long, Rhonda -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470882: /dev/gpmctl freezes acknowledge
Gerfried Fuchs, le Wed 12 Nov 2008 14:43:19 +0100, a écrit : The unfortunate effect here is that it waits without handling clients. The attached patch fixes that: when not in text mode, the mouse is closed, but the select() loop continues. I had to change the timeout of select, I have made it 2 seconds, like the latency of the previously-used wait_text(). That should fix the hang of clients. Are you sure with that fix? Definitely. I applied it and did a local rebuild, and now pdmenu segfaults on any keypress after starting. I don't really call that an improvment. :) It is: now you at least get a connexion, and get rejected. The pdmenu segfault is due to another bug, see my mail dated 11th October. The problem is that pdmenu tries to connect to gpm, but because it is not running as root or as the owner of the console ttys, the server eventually rejects it (_after_ having received some data, because on some systems it's the only way to get the credentials), i.e. the server closes the connection, the client gets an EOF, closes it too, and sets gpm_fd to -1. Then pdmenu uses it in a FD_SET() call. SEGFAULT. One way to fix it would be in the client to create a pipe, and dup2() the read side into the gpm_fd, in order to keep the fd never readable again. It's quite ugly, but that's the only way I can see to fix clients that use gpm_fd without taking care. Else we have to fix all the clients. (Note that if gpm is restarted, you get the same issue: the client gets an EOF etc). Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470882: /dev/gpmctl freezes acknowledge
clone 470882
retitle -1 pdmenu should check the value returned by Gpm_GetEvent()
reassign -1 pdmenu
thanks
Reading the documentation of Gpm_GetEvent:
« It returns 1 on success, -1 on failure, and 0 after closing the connection. »
pdmenu doesn't properly check that. It should. Patch attached.
Samuel
--- src/mouse.c.orig2008-11-13 01:37:55.0 +0100
+++ src/mouse.c 2008-11-13 01:38:10.0 +0100
@@ -45,8 +45,11 @@
retval = select(gpm_fd+1, rfds, NULL, NULL, tv);
if (retval) { /* data available */
- if ((FD_ISSET(gpm_fd, rfds)) /* data is for mice */
- (Gpm_GetEvent(event))) { /* can read something */
+ if (FD_ISSET(gpm_fd, rfds)) {
+ /* data is for mice */
+ switch (Gpm_GetEvent(event)) {
+ case 1:
+ /* can read something */
if ((event.type GPM_DOWN) (event.buttons GPM_B_LEFT))
return(MOUSE_BUTTON_LEFT);
if ((event.type GPM_DOWN) (event.buttons GPM_B_RIGHT))
@@ -55,6 +58,15 @@
return(MOUSE_DOWN);
if (event.dy 0)
return(MOUSE_UP);
+ break;
+ case -1:
+ /* can read nothing */
+ break;
+ case 0:
+ /* disconnected */
+ gpm_ok = 0;
+ return(MOUSE_NOTHING);
+ } /* switch */
} else { /* data is for keyboard */
return(MOUSE_NOTHING);
} /* else */
Bug#470882: /dev/gpmctl freezes acknowledge
tags 470882 + patch
thanks
Hello,
Christoph Berg, le Sat 25 Oct 2008 20:47:08 +0200, a écrit :
I suspect the following code from old_main() is bogus:
if(kd_mode != KD_TEXT !option.repeater !option.force_repeat) {
wait_text(mouse_table[1].fd);
What does it mean to be in text mode? What if X is started later?
As already said, that's not a problem.
Does gpm assume that all X users will need to enable a repeater?
Precisely no.
The problem is that you both want a mouse on the text console and a
mouse in X. The correct way is to use a repeater: gpm reads
/dev/input/mice, and repeats to X. Now, gpm tries to play nice with X
servers that would read /dev/input/mice themselves: if a repeater is not
setup, then when not in text mode gpm closes the mouse (to let X open
it).
The unfortunate effect here is that it waits without handling clients.
The attached patch fixes that: when not in text mode, the mouse
is closed, but the select() loop continues. I had to change the
timeout of select, I have made it 2 seconds, like the latency of the
previously-used wait_text(). That should fix the hang of clients.
Samuel
--- src/daemon/old_main.c.orig 2008-11-11 22:06:41.0 +0100
+++ src/daemon/old_main.c 2008-11-11 22:06:25.0 +0100
@@ -130,10 +130,8 @@
FD_SET(mouse_table[eventFlag].fd,selSet);
}
else
-
while((pending=select(maxfd+1,selSet,NULL_SET,NULL_SET,timeout))==0){
-selSet=readySet;
+ if((pending=select(maxfd+1,selSet,NULL_SET,NULL_SET,timeout))==0)
resetTimeout();
- } /* go on */
if(opt_resize) { /* did the console resize? */
get_console_size(event);
@@ -168,12 +166,24 @@
if (ioctl(fd, KDGETMODE, kd_mode) 0)
gpm_report(GPM_PR_OOPS,GPM_MESS_IOCTL_KDGETMODE);
close(fd);
- if(kd_mode != KD_TEXT !option.repeater !option.force_repeat) {
- wait_text(mouse_table[1].fd);
- maxfd=max(maxfd,mouse_table[1].fd);
- readySet=connSet;
- FD_SET(mouse_table[1].fd,readySet);
- continue; /* reselect */
+ if (!option.repeater !option.force_repeat) {
+ if (mouse_table[1].fd = 0 kd_mode != KD_TEXT) {
+/* Non-text mode, close mouse */
+close(mouse_table[1].fd);
+FD_CLR(mouse_table[1].fd,readySet);
+mouse_table[1].fd=-1;
+ } else if (mouse_table[1].fd 0 kd_mode == KD_TEXT) {
+/* Back to text mode, reopen mouse */
+if ((mouse_table[1].fd=open((mouse_table[1].opt_dev),O_RDWR))0)
+ gpm_report(GPM_PR_OOPS,GPM_MESS_OPEN,(mouse_table[1].opt_dev));
+else {
+ if ((mouse_table[1].m_type)-init)
+
(mouse_table[1].m_type)=((mouse_table[1].m_type)-init)(mouse_table[1].fd,
(mouse_table[1].m_type)-flags, (mouse_table[1].m_type), mouse_argc[1],
+ mouse_argv[1]);
+ maxfd=max(maxfd,mouse_table[1].fd);
+ FD_SET(mouse_table[1].fd,readySet);
+}
+ }
}
}
@@ -185,7 +195,7 @@
for (i=1; i = 1+opt_double; i++) {
which_mouse=mouse_table+i; /* used to access options */
- if (FD_ISSET(which_mouse-fd,selSet)) {
+ if (which_mouse-fd = 0 FD_ISSET(which_mouse-fd,selSet)) {
FD_CLR(which_mouse-fd,selSet); pending--;
if (processMouse(which_mouse-fd, event, (which_mouse-m_type),
kd_mode))
/* pass it to the client, if any
--- src/headers/gpmInt.h.orig 2008-11-11 22:01:25.0 +0100
+++ src/headers/gpmInt.h2008-11-11 22:01:32.0 +0100
@@ -33,7 +33,7 @@
/*... old gpmCfg.h */
/* timeout for the select() syscall */
-#define SELECT_TIME 86400 /* one day */
+#define SELECT_TIME 2 /* two seconds */
#ifdef HAVE_LINUX_TTY_H
#include linux/tty.h
Processed: Re: Bug#470882: /dev/gpmctl freezes acknowledge
Processing commands for [EMAIL PROTECTED]: tags 470882 + patch Bug#470882: gpm freezes and makes other applications freeze/segfault There were no tags set. Bug#476431: gpm makes apps hang if running; they run normally if stopped Tags added: patch thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470882: /dev/gpmctl freezes acknowledge
Hello, Same for me, I've always had the repeater, thus couldn't reproduce the 7th bug. Christoph Berg, le Sat 25 Oct 2008 20:47:08 +0200, a écrit : Or is the bug rather that applications not running on a linux consule must not try to connect to gpm? Ideally they shouldn't even try, yes. And they used to not try, see bug #472063. In this case, gpm should probably still reject the connection in some way. Yes. The problem is that then you get the crash whose backtrace can be read in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470882#135 : it looks like libgpm can not afford just closing its fd and setting gpm_fd to -1 since the application could still e.g. add it to an fd_set or have done it already (and then get a EBADF). Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470882: /dev/gpmctl freezes acknowledge
[http://wiki.debian.org/BugSprint is to blame for me looking into this]
As the locking occurs on exactly the 7th event (using rxvt-unicode +
pdmenu here), there must be kept some state somewhere. That's most
likely gpm.
Client applications try to connect() to /dev/gpmctl, but starting from
the 7th try, this locks up. Stracing gpm shows that it doesn't ever
accept() the connection, not on the first tries, nor later. gdb shows
it loops in wait_text() from which it never exits:
#0 0x7f41a2a13fc0 in nanosleep () from /lib/libc.so.6
#1 0x7f41a2a13e17 in sleep () from /lib/libc.so.6
#2 0x0041378a in wait_text (fdptr=0x61c2a8) at daemon/wait_text.c:38
#3 0x00410172 in old_main () at daemon/old_main.c:172
#4 0x0040f705 in main (argc=5, argv=0x7fffab167d88) at daemon/main.c:33
The bit that would accept() connections is processConn() is never
reached because old_main() continues the loop earlier.
So far I managed to find a way to work around the problem by starting
gpm with the -F (force repeat) option:
#0 0x7f8b5e95ec93 in select () from /lib/libc.so.6
#1 0x0040ff05 in old_main () at daemon/old_main.c:133
#2 0x0040f719 in main (argc=6, argv=0x7fff67087c98) at daemon/main.c:33
Now pdmenu doesn't lock up anymore.
I suspect the following code from old_main() is bogus:
/*
* Be sure to be in text mode. This used to be before select,
* but actually it only matters if you have events.
*/
{
int fd = open_console(O_RDONLY);
if (ioctl(fd, KDGETMODE, kd_mode) 0)
gpm_report(GPM_PR_OOPS,GPM_MESS_IOCTL_KDGETMODE);
close(fd);
if(kd_mode != KD_TEXT !option.repeater !option.force_repeat) {
wait_text(mouse_table[1].fd);
What does it mean to be in text mode? What if X is started later?
Does gpm assume that all X users will need to enable a repeater? Since
/dev/input/mice exists, that's no longer true, afaict.
Or is the bug rather that applications not running on a linux consule
must not try to connect to gpm? In this case, gpm should probably
still reject the connection in some way.
Christoph
--
[EMAIL PROTECTED] | http://www.df7cb.de/
signature.asc
Description: Digital signature
Bug#470882: /dev/gpmctl freezes acknowledge
On Sat, Oct 25, 2008 at 08:47:08PM +0200, Christoph Berg wrote:
I suspect the following code from old_main() is bogus:
/*
* Be sure to be in text mode. This used to be before select,
* but actually it only matters if you have events.
*/
{
int fd = open_console(O_RDONLY);
if (ioctl(fd, KDGETMODE, kd_mode) 0)
gpm_report(GPM_PR_OOPS,GPM_MESS_IOCTL_KDGETMODE);
close(fd);
if(kd_mode != KD_TEXT !option.repeater !option.force_repeat) {
wait_text(mouse_table[1].fd);
What does it mean to be in text mode? What if X is started later?
It return 0 (KD_TEXT) when the _current_ console is a text console
and 1 (KD_GRAPHICS) when you're in X. It has nothing to do with
what console gpm runs on, since it's detached.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470882: /dev/gpmctl freezes acknowledge
On Sat, Oct 25, 2008 at 08:47:08PM +0200, Christoph Berg wrote:
[http://wiki.debian.org/BugSprint is to blame for me looking into this]
As the locking occurs on exactly the 7th event (using rxvt-unicode +
pdmenu here), there must be kept some state somewhere. That's most
likely gpm.
Restarting gpm makes it work again.
So far I managed to find a way to work around the problem by starting
gpm with the -F (force repeat) option:
I've always used the -R option which I probably don't need anymore,
so I guess that's why I couldn't reproduce it.
int fd = open_console(O_RDONLY);
if (ioctl(fd, KDGETMODE, kd_mode) 0)
gpm_report(GPM_PR_OOPS,GPM_MESS_IOCTL_KDGETMODE);
close(fd);
if(kd_mode != KD_TEXT !option.repeater !option.force_repeat) {
wait_text(mouse_table[1].fd);
You know that you're looking at the code from experimental, right?
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470882: /dev/gpmctl freezes acknowledge
Re: Kurt Roeckx 2008-10-25 [EMAIL PROTECTED]
if(kd_mode != KD_TEXT !option.repeater !option.force_repeat) {
wait_text(mouse_table[1].fd);
What does it mean to be in text mode? What if X is started later?
It return 0 (KD_TEXT) when the _current_ console is a text console
and 1 (KD_GRAPHICS) when you're in X. It has nothing to do with
what console gpm runs on, since it's detached.
That code runs in the server. wait_text() doesn't return while X is
shown on the console, and that makes the connect()s from libgpm pile
up, and finally block.
Christoph
--
[EMAIL PROTECTED] | http://www.df7cb.de/
signature.asc
Description: Digital signature
Bug#470882: /dev/gpmctl freezes acknowledge
Re: Kurt Roeckx 2008-10-25 [EMAIL PROTECTED]
int fd = open_console(O_RDONLY);
if (ioctl(fd, KDGETMODE, kd_mode) 0)
gpm_report(GPM_PR_OOPS,GPM_MESS_IOCTL_KDGETMODE);
close(fd);
if(kd_mode != KD_TEXT !option.repeater !option.force_repeat) {
wait_text(mouse_table[1].fd);
You know that you're looking at the code from experimental, right?
gpm (1.20.4-2) unstable; urgency=low
-- Guillem Jover [EMAIL PROTECTED] Sun, 22 Jun 2008 09:38:10 +0300
Same version is also in testing.
Christoph
--
[EMAIL PROTECTED] | http://www.df7cb.de/
signature.asc
Description: Digital signature
Bug#470882: /dev/gpmctl freezes acknowledge
On Sat, Oct 25, 2008 at 10:09:35PM +0200, Christoph Berg wrote:
Re: Kurt Roeckx 2008-10-25 [EMAIL PROTECTED]
int fd = open_console(O_RDONLY);
if (ioctl(fd, KDGETMODE, kd_mode) 0)
gpm_report(GPM_PR_OOPS,GPM_MESS_IOCTL_KDGETMODE);
close(fd);
if(kd_mode != KD_TEXT !option.repeater !option.force_repeat) {
wait_text(mouse_table[1].fd);
You know that you're looking at the code from experimental, right?
gpm (1.20.4-2) unstable; urgency=low
It seems I didn't look at the source with the patches applied.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470882: /dev/gpmctl freezes acknowledge
Re: Kurt Roeckx 2008-10-25 [EMAIL PROTECTED] gpm (1.20.4-2) unstable; urgency=low It seems I didn't look at the source with the patches applied. Btw, I had tried disabling some patches, but the result was the same. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#470882: /dev/gpmctl freezes acknowledge
On Thu, Oct 09, 2008 at 01:14:28AM +0200, Samuel Thibault wrote: Now, that being said, that reminds me bug #472063: actually libgpm shouldn't even have tried to connect to the server, it should have just noticed it is running in an X terminal and set gpm_fd to -2... Both people reporting this bug seem to be using rxvt-unicode, and #472063 is also about that. #472063 is also still open. So I've tried a few different things. Using aptitude: - virtual console shows mouse, but doesn't work as expected. Clicking somewhere doesn't always seem to have an effect. Click and drag seems to have a weird effects. - xterm: the mouse icon stays the same as a normal xterm, one used for selecting text. Clicking someone does seem to have the desired effect. However, it seems that the place where the cursor is shown in other cases it just shows an empty space instead of the '-'. - rxvt-unicode: The mouse icon is also the text selecting one, and it's all that it seems to be doing. The cursor is not shown. - gnome-terminal: the mouse icon is a normal pointer. It also works as expected. When aptitude wasn't started it was the text selection icon. - konsole: behaves the same as gnome-terminal. For w3m: - virtual console: no mouse shown, also doesn't seem to have any effect at all. - xterm: same as aptitude, but text under cursor still shown. - rxvt-unicode: same as aptitude, but the cursor is shown now. - gnome-terminal: same as aptitude. - konsole: same as aptitude. For pdmenu: - virtual console: no mouse shown, but moving it changes the current line of the menu. It's shown in white on black, no colors. - xterm, rxvt-unicode, gnome-terminal, konsole: Just selection of text. They all show it in color, rxvt-unicode with a grey background, the rest with a blue background. So it seems to me that the problem might be in the terminal emulator. I was not able to reproduce any hanging or segfaults or something simular. Packages used: aptitude 0.4.11.8-1 gpm1.20.4-2 libncurses55.6+20080830-1 w3m0.5.2-2+b1 rxvt-unicode 9.05-1 gnome-terminal 2.22.3-3 xterm 235-1 konsole4:3.5.9.dfsg.1-5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470882: /dev/gpmctl freezes acknowledge
On Sun, Oct 12, 2008 at 12:19:49PM +0200, Kurt Roeckx wrote: On Thu, Oct 09, 2008 at 01:14:28AM +0200, Samuel Thibault wrote: Now, that being said, that reminds me bug #472063: actually libgpm shouldn't even have tried to connect to the server, it should have just noticed it is running in an X terminal and set gpm_fd to -2... Both people reporting this bug seem to be using rxvt-unicode, and #472063 is also about that. #472063 is also still open. So I've tried a few different things. Using aptitude: - virtual console shows mouse, but doesn't work as expected. Clicking somewhere doesn't always seem to have an effect. Click and drag seems to have a weird effects. ncurses is only using a click-style interface for GPM (no dragging). As I recall it, GPM also has some built-in behavior for select/paste which ncurses doesn't try to work around. - xterm: the mouse icon stays the same as a normal xterm, one used for selecting text. Clicking someone does seem to have the desired effect. However, it seems that the place where the cursor is shown in other cases it just shows an empty space instead of the '-'. I'm not sure why ncurses would behave different from gnome/konsole here. The description isn't clear (to me) though... (coincidentally, I was just testing gnome-terminal with vttest, seeing some mouse-related bugs there ;-) - rxvt-unicode: The mouse icon is also the text selecting one, and it's all that it seems to be doing. The cursor is not shown. that may depend on the terminfo (Debian maintains that one). - gnome-terminal: the mouse icon is a normal pointer. It also works as expected. When aptitude wasn't started it was the text selection icon. - konsole: behaves the same as gnome-terminal. For w3m: - virtual console: no mouse shown, also doesn't seem to have any effect at all. - xterm: same as aptitude, but text under cursor still shown. - rxvt-unicode: same as aptitude, but the cursor is shown now. - gnome-terminal: same as aptitude. - konsole: same as aptitude. For pdmenu: - virtual console: no mouse shown, but moving it changes the current line of the menu. It's shown in white on black, no colors. - xterm, rxvt-unicode, gnome-terminal, konsole: Just selection of text. They all show it in color, rxvt-unicode with a grey background, the rest with a blue background. So it seems to me that the problem might be in the terminal emulator. I was not able to reproduce any hanging or segfaults or something simular. Packages used: aptitude 0.4.11.8-1 gpm1.20.4-2 libncurses55.6+20080830-1 w3m0.5.2-2+b1 rxvt-unicode 9.05-1 gnome-terminal 2.22.3-3 xterm 235-1 konsole 4:3.5.9.dfsg.1-5 -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpVvTzvIT84N.pgp Description: PGP signature
Bug#470882: /dev/gpmctl freezes acknowledge
* Samuel Thibault [EMAIL PROTECTED] [2008-10-10 13:21:49 CEST]: Gerfried Fuchs, le Fri 10 Oct 2008 13:10:35 +0200, a écrit : ii libncurses55.6+20081004-1shared libraries for terminal hand Doesn't solve the issue, unfortunately. Ok so you're encountering another bug than what I've noticed. Am I right in thinking that this only happens in an xterm, not on the text console? I'm using an rxvt-unicode, but yes. First time tried to test it in a virtual console and indeed, the bug doesn't appear to happen there, started pdmenu for at least 20 times without troubles. Did give it another test: When pdmenu hangs and switching from X11 to virtual console and back, pdmenu displayed its menu, but pressing any key will make it segfault from that state. So long, Rhonda -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470882: /dev/gpmctl freezes acknowledge
* Thomas Dickey [EMAIL PROTECTED] [2008-10-10 13:30:18 CEST]: On Fri, Oct 10, 2008 at 01:10:35PM +0200, Gerfried Fuchs wrote: w3m 0.5.2-2+b1, Versions of packages w3m depends on: I already commented on w3m. It's using names from ncurses without actually using the ncurses library, to fool gpm into working by calling w3m's code. Ah, sorry. ...Of the programs mentioned, ncurses updates should only affect aptitude. pdmenu does not appear to rely on ncurses (see my first reply). Hanging pdmenu doesn't affect aptitude usage. I'm currently downgrading ncurses5 again to test wether that is really an improvement, wasn't sure how it was before that. Yes, downgrading ncurses5 makes aptitude hang, too. So long, Rhonda -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476431: Bug#470882: /dev/gpmctl freezes acknowledge
Gerfried Fuchs, le Fri 10 Oct 2008 13:10:35 +0200, a écrit : ii libncurses55.6+20081004-1shared libraries for terminal hand Doesn't solve the issue, unfortunately. Ok so you're encountering another bug than what I've noticed. Am I right in thinking that this only happens in an xterm, not on the text console? Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476431: Bug#470882: /dev/gpmctl freezes acknowledge
On Thu, Oct 09, 2008 at 11:59:43PM +0200, Samuel Thibault wrote: Thomas Dickey, le Wed 08 Oct 2008 20:00:32 -0400, a écrit : With the latest update, ncurses won't try to use gpm if $TERM doesn't contain linux, unless it's overridden (with a new environment variable). Ah, indeed. Rhonda, Zito or Simon, could you check whether upgrading your libncurses5 and libncursesw5 to 5.6+20081004-1 fixes the bug? I think that should fix it for the usual cases. Yes, upgrade solved my problem - aptitude, m-a at least. I tried start these 10 times and freeze didn't occured. I'm using Unicode Rxvt X terminal emulator. [EMAIL PROTECTED]:~$ echo $TERM rxvt-unicode I tested problem with 5.6+20080925-1 positively, than upgrade to 5.6+20081004-1 and it is OK now. ii libncurses55.6+20081004-1 shared libraries for terminal handling Regards -- Zito -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470882: /dev/gpmctl freezes acknowledge
* Samuel Thibault [EMAIL PROTECTED] [2008-10-09 23:59:43 CEST]: Thomas Dickey, le Wed 08 Oct 2008 20:00:32 -0400, a écrit : With the latest update, ncurses won't try to use gpm if $TERM doesn't contain linux, unless it's overridden (with a new environment variable). Ah, indeed. Rhonda, Zito or Simon, could you check whether upgrading your libncurses5 and libncursesw5 to 5.6+20081004-1 fixes the bug? I think that should fix it for the usual cases. These packages are currently installed: w3m 0.5.2-2+b1, Versions of packages w3m depends on: ii libc6 2.7-13GNU C Library: Shared libraries ii libgc1c2 1:6.8-1.1 conservative garbage collector for ii libgpm21.20.4-2 General Purpose Mouse - shared lib ii libncurses55.6+20081004-1shared libraries for terminal hand ii libssl0.9.80.9.8g-13 SSL shared libraries ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Doesn't solve the issue, unfortunately. I've upgraded all my ncurses packages, after that started gpm and did run and quit 'w3m http://nm.debian.org/' exactly seven times (reproducible), likewise with pdmenu: #v+ [EMAIL PROTECTED]:~$ sudo /etc/init.d/gpm start Starting mouse interface server: gpm. [EMAIL PROTECTED]:~$ pdmenu [EMAIL PROTECTED]:~$ pdmenu [EMAIL PROTECTED]:~$ pdmenu [EMAIL PROTECTED]:~$ pdmenu [EMAIL PROTECTED]:~$ pdmenu [EMAIL PROTECTED]:~$ pdmenu [EMAIL PROTECTED]:~$ pdmenu #v- Did press x and enter in the started pdmenu, the last one just hangs and doesn't start until gpm is stopped again. Thanks for keeping an eye on it, if there's more I can do, just let me know. So long, Rhonda -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470882: /dev/gpmctl freezes acknowledge
On Fri, Oct 10, 2008 at 01:10:35PM +0200, Gerfried Fuchs wrote: * Samuel Thibault [EMAIL PROTECTED] [2008-10-09 23:59:43 CEST]: Thomas Dickey, le Wed 08 Oct 2008 20:00:32 -0400, a écrit : With the latest update, ncurses won't try to use gpm if $TERM doesn't contain linux, unless it's overridden (with a new environment variable). Ah, indeed. Rhonda, Zito or Simon, could you check whether upgrading your libncurses5 and libncursesw5 to 5.6+20081004-1 fixes the bug? I think that should fix it for the usual cases. These packages are currently installed: w3m 0.5.2-2+b1, Versions of packages w3m depends on: I already commented on w3m. It's using names from ncurses without actually using the ncurses library, to fool gpm into working by calling w3m's code. See http://invisible-island.net/ncurses/ncurses.faq.html#using_gpm_lib ii libc6 2.7-13GNU C Library: Shared libraries ii libgc1c2 1:6.8-1.1 conservative garbage collector for ii libgpm21.20.4-2 General Purpose Mouse - shared lib ii libncurses55.6+20081004-1shared libraries for terminal hand ii libssl0.9.80.9.8g-13 SSL shared libraries ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Doesn't solve the issue, unfortunately. I've upgraded all my ncurses packages, after that started gpm and did run and quit 'w3m http://nm.debian.org/' exactly seven times (reproducible), likewise with pdmenu: ...Of the programs mentioned, ncurses updates should only affect aptitude. pdmenu does not appear to rely on ncurses (see my first reply). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpxORA8HfRKv.pgp Description: PGP signature
Bug#470882: /dev/gpmctl freezes acknowledge
Thomas Dickey, le Wed 08 Oct 2008 20:00:32 -0400, a écrit : b) I'm not as familiar with pdmenu source - but reading, seems to talk directly to gpm using its documented interface, and to be using slang. I tried to reproduce it, same issue indeed: Program received signal SIGBUS, Bus error. CheckMouse () at ../src/mouse.c:39 39 FD_SET(gpm_fd, rfds); (gdb) bt #0 CheckMouse () at ../src/mouse.c:39 #1 0x00404072 in DoMenu (m=0x1f79d10, MenuAction=0x402c80 Pdmenu_Action, Ctrl_C_Action=0x402ca0 Handle_Ctrl_C) at ../src/menu.c:336 #2 0x00404e62 in main (argc=value optimized out, argv=0x7fff9a00ff08) at ../src/pdmenu.c:275 (gdb) p gpm_fd $1 = -1 pdmenu doesn't like gpm_fd becoming -1 under its feet. I haven't been able to reproduce the issue with w3m. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476431: Bug#470882: /dev/gpmctl freezes acknowledge
Thomas Dickey, le Wed 08 Oct 2008 20:00:32 -0400, a écrit : With the latest update, ncurses won't try to use gpm if $TERM doesn't contain linux, unless it's overridden (with a new environment variable). Ah, indeed. Rhonda, Zito or Simon, could you check whether upgrading your libncurses5 and libncursesw5 to 5.6+20081004-1 fixes the bug? I think that should fix it for the usual cases. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470882: /dev/gpmctl freezes acknowledge
Just to summarize a few things:
- apparently it happens just for clients run in an terminal in X.
- the server logs previously attached to the bug show
Failed gpm connect attempt by uid 1000 for vc /dev/tty0
which means that libgpm tried to connect to the gpm server, and failed
since it didn't know which VT to acquire, thus tried tty0, and failed
since it probably belongs to root, not to uid 1000.
I tried to reproduce that, and I noticed something in the strace I could
get:
# the client logs the connection error
sendto(52, 14Oct 9 00:55:37 aptitude: *** info, 39, MSG_NOSIGNAL, NULL, 0)
= 39
sendto(52, 14Oct 9 00:55:37 aptitude: Warning: closing connection, 57,
MSG_NOSIGNAL, NULL, 0) = 57
# closes the socket
close(4)
...
# and still tries to select it!
select(5, [0 4], NULL, NULL, {0, 166000}) = -1 EBADF (Bad file descriptor)
it looks like the caller of libgpm didn't notice that gpm_fd is not
a valid file descriptor any more. In the case of aptitude, that's
ncurses... Thomas?
Now, that being said, that reminds me bug #472063: actually libgpm
shouldn't even have tried to connect to the server, it should have just
noticed it is running in an X terminal and set gpm_fd to -2...
Samuel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470882: /dev/gpmctl freezes acknowledge
On Thu, Oct 09, 2008 at 01:14:28AM +0200, Samuel Thibault wrote:
Just to summarize a few things:
recap - there's more than one client scenario:
a) w3m, the last I looked, was abusing ncurses interface to
access gpm in its own way. I'll keep in mind to not break
it, but its usage is completely unsupported.
b) I'm not as familiar with pdmenu source - but reading, seems to
talk directly to gpm using its documented interface, and to
be using slang.
c) aptitude is using ncurses via cwidgets (this might be mine ;-)
- apparently it happens just for clients run in an terminal in X.
- the server logs previously attached to the bug show
Failed gpm connect attempt by uid 1000 for vc /dev/tty0
which means that libgpm tried to connect to the gpm server, and failed
since it didn't know which VT to acquire, thus tried tty0, and failed
since it probably belongs to root, not to uid 1000.
I tried to reproduce that, and I noticed something in the strace I could
get:
# the client logs the connection error
sendto(52, 14Oct 9 00:55:37 aptitude: *** info, 39, MSG_NOSIGNAL, NULL,
0) = 39
sendto(52, 14Oct 9 00:55:37 aptitude: Warning: closing connection, 57,
MSG_NOSIGNAL, NULL, 0) = 57
# closes the socket
close(4)
...
# and still tries to select it!
select(5, [0 4], NULL, NULL, {0, 166000}) = -1 EBADF (Bad file descriptor)
it looks like the caller of libgpm didn't notice that gpm_fd is not
a valid file descriptor any more. In the case of aptitude, that's
ncurses... Thomas?
Now, that being said, that reminds me bug #472063: actually libgpm
shouldn't even have tried to connect to the server, it should have just
noticed it is running in an X terminal and set gpm_fd to -2...
With the latest update, ncurses won't try to use gpm if $TERM doesn't
contain linux, unless it's overridden (with a new environment variable).
Before the immediate changes of the past month - ncurses would try to
use gpm - and I agree that it should have failed since I'd expect gpm_fd
to be returned as a negative value. That check is made in one place in
lib_mouse.c:
result = (my_Gpm_Open(SP-_mouse_gpm_connect, 0) = 0);
I noticed that for some reason it was _not_ failing, when the gpm server was
running, but did not dig into the gpm package (just examined the source code
w/o seeing the problem). As I recall it, ncurses did both checks because
some previous users insisted that gpm works in xterm.
But that issue prompted me to add the additional restriction, to move
away from gpm a little further.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
pgpPm4zsrdV6O.pgp
Description: PGP signature
Bug#470882: /dev/gpmctl freezes acknowledge
Package: gpm Version: 1.20.3~pre3-3 Followup-For: Bug #470882 Hi, I have this problem on my box and another two boxes at home too. Gpm enabled applications freezes on communication with gpm. When I switch to the console to see if mouse is functional under gpm right now (aptitude hangs in rxvt) - mouse moves ok in text console. Applications (aptitude, module-assistant,...) revive after gpm restart. This problem appears several times a day for me. It is sufficient to enter/quit aptitude or m-a six times (perhaps exactly six times!) and problem arises (I check this several times with aptitude now). Seventh enter is lockup. When I leave locked aptitude in rxvt, switch to the text console, move around mouse a moment, go back into the X-Window, aptitude revives. Best Regards -- Zito -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=cs_CZ.ISO-8859-2 (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/bash Versions of packages gpm depends on: ii debconf [debconf-2.0] 1.5.21Debian configuration management sy ii debianutils2.28.5Miscellaneous utilities specific t ii libc6 2.7-10GNU C Library: Shared libraries ii libgpmg1 1.20.3~pre3-3 General Purpose Mouse - shared lib ii lsb-base 3.2-11Linux Standard Base 3.2 init scrip ii ucf3.006 Update Configuration File: preserv gpm recommends no packages. -- debconf information: * gpm/responsiveness: 16 * gpm/repeat_type: * gpm/append: -S * gpm/restart: false * gpm/sample_rate: * gpm/type: imps2 * gpm/device: /dev/input/mice * gpm/restart_default: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470882: /dev/gpmctl freezes acknowledge
Hello! Vaclav Ovsik [Wed, Apr 30, 2008 at 08:36:42AM +0200]: Hi, I have this problem on my box and another two boxes at home too. Gpm enabled applications freezes on communication with gpm. When I switch to the console to see if mouse is functional under gpm right now (aptitude hangs in rxvt) - mouse moves ok in text console. Applications (aptitude, module-assistant,...) revive after gpm restart. This problem appears several times a day for me. Can you do strace -Ff program 2 log before starting the program that hangs? And can you run gpm -D options gpm.log 21 on another console before? And then send both files to me? Nico -- Think about Free and Open Source Software (FOSS). http://nico.schottelius.org/documentations/foss/the-term-foss/ PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C signature.asc Description: Digital signature
