Bug#329901: xterm freezes when starting mc
On Thu, Nov 02, 2006 at 07:05:34PM +0100, Jan Gorski wrote: > > Or perhaps the xinerama configuration limits the amount of X resource data > > that is stored, to allow for multiple screens. > > Well, I looked for xinerama bugs, and voila > > https://bugs.freedesktop.org/show_bug.cgi?id=3040 > > So maybe move this bug to libxinerama package? yes - that report sounds like what you're seeing. > > If it is only the (size of the) font, you might be able to compare other > > applications loading the font, to see if they are successful. xfd would > > give > > some insight (though I expect it uses less resources than xterm). > > xfd loads terminus, but application looks strange (see attached xfd.jpg) > There is no text above main table, also first column of table is empty. > It seems to be the same problem as when starting xterm has no visible command > prompt. Triggering exposure event restores text in xfd correctly. ok (I don't know the likely failure mode, but can make some guesses) > > A web browser would probably use more resources, though getting it to load a > > specific font might be hard. > > Probably the other bug (loosing ability to change focus from web browser to > anything else under fvwm) is also related to fonts and xinerama. thanks > Regards > Jan Górski -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpDlCICTLQfC.pgp Description: PGP signature
Bug#329901: xterm freezes when starting mc
On Thu, Nov 02, 2006 at 01:55:41PM +0100, Jan Gorski wrote:
> On Wed, 01 Nov 2006 at 19:51:20 -0500, Thomas Dickey wrote:
> > You could add a printf to get the number of screens in the display,
> > e.g., I did this (enabling trace), but a printf would also work:
> >
> > Trace("FIXME %d\n", dpy->default_screen);
> > Trace("FIXME %d\n", dpy->nscreens);
> > if (XParseColor(screen->display, cmap, spec, &def)
>
> Well, dpy is no defined in function AllocateAnsiColor(...), I used:
sorry - I should have pasted that - something like
Display *dpy = screen->display;
> printf("Before XParseColor\n def_screen = %d\n nscreens = %d\n",
> DefaultScreen(screen->display),
> ScreenCount(screen->display));
>
> But I did not any programming in plain X and am not sure if this is what you
> wanted to see.
that looks right (thanks)
> > For the normal single-screen, that's default_screen=0, nscreens=1.
>
> My code gives
>
> (gdb) run
> Starting program: /home/slimak/kodowanie/got/debian/xterm-210/xterm
> (start mc here)
> XXX Before XParseColor
> def_screen = 0
> nscreens = 1
> (those three lines repeated few times)
ok - then my guess was wrong. It seems that xinerama is presenting a single
screen to the application. That's good since I don't have to change xterm
to work with that, bad since it's pointing to the X libraries or server.
Oddhand, I _think_ the poll() call is from the X libraries talking to the
X server.
> both on single and multihead configurations.
>
> Xterm allocates few colours in first run and then freezes in poll(). On
> subsequent run it allocates more colours and freezes, on third run it works.
> But
> I remember, that it is a little bit random --- some times in the past it
> needed
> more mc runnings before stopping freezes.
>
> I have also created new user and tested xterm on it --- it worked. So I
> started
> looking for a reason, and found it. If on newly created user I add .Xresources
> with this line
>
> xterm*font: -xos4-terminus-bold-r-normal--24-*-*-*-*-*-iso10646-1
>
> the problem appears if xterm is run on multihead xinerama configuration.
One issue with the iso10646 fonts is that the X server (or associated server)
has to load the font. That makes uxterm setup perhaps ten times slower than
xterm. Apparently _each_ process that requires the fonts has to get that
information separately.
Perhaps the problem is related to time.
Or perhaps the xinerama configuration limits the amount of X resource data
that is stored, to allow for multiple screens.
> On single head it works fine.
>
> Another strange thing --- it somtimes happens, that after starting xterm (on
> multihead and with changed font) it is completly white --- the command promt
> is
> not visible. New characters are visible.
From xterm's viewpoint, that could be a missed exposure event, or it could
mean that some colors were not allocated. (Sometimes it is time-dependent,
so I cannot always see things like that in a trace).
> > Next - to see if xterm is seeing more than one screen, if being started
> > on the second screen is the cause of the problem (confusing X), and if so,
> > whether the display information passed to xterm can tell it to use a
> > different screen number. If that's the explanation, I can modify xterm
> > to take that into account. (If it's not, I'm still puzzled ;-)
>
> Thats part of my xorg.conf
>
> Section "ServerLayout"
> Identifier "ii19ii22"
> Screen 0 "II22 NV436" 1280 0
> Screen 1 "II19 NV432" 0 0
> Option "Xinerama"
> InputDevice"HHKB"
> InputDevice"Mysz A4Tech 0"
> Option "CustomKeycode" "on"
> EndSection
>
> xterm starts always on left screen, which is Screen 1
> but when using xinerama there is no screen :0.1 ---
>
> [EMAIL PROTECTED]:~$ set |grep DISP
> DISPLAY=:0.0
> [EMAIL PROTECTED]:~$ xterm -display :0.1
> xterm Xt error: Can't open display: :0.1
>
> As I recall xinerama merges all screens --- it even allows overlapping of
> them.
ok - I was unfamiliar with it on the initial report. But reading about it
since then, it does sound as if its operation is intended to be transparent.
If it is only the (size of the) font, you might be able to compare other
applications loading the font, to see if they are successful. xfd would give
some insight (though I expect it uses less resources than xterm). A web
browser would probably use more resources, though getting it to load a specific
font might be hard.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
pgpuPVAYGq5Pb.pgp
Description: PGP signature
Bug#329901: xterm freezes when starting mc
On Wed, 01 Nov 2006 at 19:51:20 -0500, Thomas Dickey wrote:
> You could add a printf to get the number of screens in the display,
> e.g., I did this (enabling trace), but a printf would also work:
>
> Trace("FIXME %d\n", dpy->default_screen);
> Trace("FIXME %d\n", dpy->nscreens);
> if (XParseColor(screen->display, cmap, spec, &def)
Well, dpy is no defined in function AllocateAnsiColor(...), I used:
printf("Before XParseColor\n def_screen = %d\n nscreens = %d\n",
DefaultScreen(screen->display),
ScreenCount(screen->display));
But I did not any programming in plain X and am not sure if this is what you
wanted to see.
> For the normal single-screen, that's default_screen=0, nscreens=1.
My code gives
(gdb) run
Starting program: /home/slimak/kodowanie/got/debian/xterm-210/xterm
(start mc here)
XXX Before XParseColor
def_screen = 0
nscreens = 1
(those three lines repeated few times)
both on single and multihead configurations.
Xterm allocates few colours in first run and then freezes in poll(). On
subsequent run it allocates more colours and freezes, on third run it works. But
I remember, that it is a little bit random --- some times in the past it needed
more mc runnings before stopping freezes.
I have also created new user and tested xterm on it --- it worked. So I started
looking for a reason, and found it. If on newly created user I add .Xresources
with this line
xterm*font: -xos4-terminus-bold-r-normal--24-*-*-*-*-*-iso10646-1
the problem appears if xterm is run on multihead xinerama configuration.
On single head it works fine.
Another strange thing --- it somtimes happens, that after starting xterm (on
multihead and with changed font) it is completly white --- the command promt is
not visible. New characters are visible.
> Next - to see if xterm is seeing more than one screen, if being started
> on the second screen is the cause of the problem (confusing X), and if so,
> whether the display information passed to xterm can tell it to use a
> different screen number. If that's the explanation, I can modify xterm
> to take that into account. (If it's not, I'm still puzzled ;-)
Thats part of my xorg.conf
Section "ServerLayout"
Identifier "ii19ii22"
Screen 0 "II22 NV436" 1280 0
Screen 1 "II19 NV432" 0 0
Option "Xinerama"
InputDevice"HHKB"
InputDevice"Mysz A4Tech 0"
Option "CustomKeycode" "on"
EndSection
xterm starts always on left screen, which is Screen 1
but when using xinerama there is no screen :0.1 ---
[EMAIL PROTECTED]:~$ set |grep DISP
DISPLAY=:0.0
[EMAIL PROTECTED]:~$ xterm -display :0.1
xterm Xt error: Can't open display: :0.1
As I recall xinerama merges all screens --- it even allows overlapping of them.
Regards
Jan Górski
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329901: xterm freezes when starting mc
On Thu, Nov 02, 2006 at 12:44:03AM +0100, Jan Gorski wrote:
> On Mon, 30 Oct 2006 at 18:50:46 -0500, Thomas Dickey wrote:
> > If you could reproduce it with a copy of xterm built with debug code,
> > then it's possible that you could attach it with gdb from another window
> > and see where it's hanging. You wouldn't need the setgid mode on the
> > executable, since it's unlikely that the utmp code is involved.
>
> That is what I have done:
thanks. The first two look more like a problem with X libraries than
xterm, though there's the possibility that mc is asking for a large
number of color changes (I don't think so...), and xterm isn't handling
it that well.
But you did say xinerama - and there's some question in my mind whether
the hang is happening on the second screen (and whether xterm is
handling a second screen properly - not being that familiar with xinerama).
xterm is using the default screen of the display, which may not be the
right thing in a multi-screen system (I'm not sure whether xinerama is
supposed to "just work").
>
> [EMAIL PROTECTED]:~/kodowanie/got/debian/xterm-210$ export CFLAGS=-g
...
> 0x2b98a5cbcc8f in poll () from /lib/libc.so.6
> (gdb) bt
> #0 0x2b98a5cbcc8f in poll () from /lib/libc.so.6
> #1 0x2b98a58e1d2f in XProcessInternalConnection () from
> /usr/lib/libX11.so.6
> #2 0x2b98a58e2142 in _XRead () from /usr/lib/libX11.so.6
> #3 0x2b98a58e2b81 in _XReply () from /usr/lib/libX11.so.6
> #4 0x2b98a58cfc3b in XParseColor () from /usr/lib/libX11.so.6
You could add a printf to get the number of screens in the display,
e.g., I did this (enabling trace), but a printf would also work:
Trace("FIXME %d\n", dpy->default_screen);
Trace("FIXME %d\n", dpy->nscreens);
if (XParseColor(screen->display, cmap, spec, &def)
For the normal single-screen, that's default_screen=0, nscreens=1.
> Starting program: /home/slimak/kodowanie/got/debian/xterm-210/xterm
> (xterm started, i run mc in it, it does no freeze this time, but i interrupt
> it anyway ;)
That's more normal - I'd expect it to be in a select() call "most" of the
time. There are some possible error conditions where it would stay there
too long (or not often enough).
Next - to see if xterm is seeing more than one screen, if being started
on the second screen is the cause of the problem (confusing X), and if so,
whether the display information passed to xterm can tell it to use a
different screen number. If that's the explanation, I can modify xterm
to take that into account. (If it's not, I'm still puzzled ;-)
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
pgpzitRzmfuOv.pgp
Description: PGP signature
Bug#329901: xterm freezes when starting mc
On Mon, 30 Oct 2006 at 18:50:46 -0500, Thomas Dickey wrote: > If you could reproduce it with a copy of xterm built with debug code, > then it's possible that you could attach it with gdb from another window > and see where it's hanging. You wouldn't need the setgid mode on the > executable, since it's unlikely that the utmp code is involved. That is what I have done: [EMAIL PROTECTED]:~/kodowanie/got/debian/xterm-210$ export CFLAGS=-g [EMAIL PROTECTED]:~/kodowanie/got/debian/xterm-210$ ./configure --enable-trace ... [EMAIL PROTECTED]:~/kodowanie/got/debian/xterm-210$ make ... [EMAIL PROTECTED]:~/kodowanie/got/debian/xterm-210$ gdb xterm GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /home/slimak/kodowanie/got/debian/xterm-210/xterm (xterm started, i started mc from xterm it got frozen, i hit ctrl-c in gdb) Program received signal SIGINT, Interrupt. 0x2b98a5cbcc8f in poll () from /lib/libc.so.6 (gdb) bt #0 0x2b98a5cbcc8f in poll () from /lib/libc.so.6 #1 0x2b98a58e1d2f in XProcessInternalConnection () from /usr/lib/libX11.so.6 #2 0x2b98a58e2142 in _XRead () from /usr/lib/libX11.so.6 #3 0x2b98a58e2b81 in _XReply () from /usr/lib/libX11.so.6 #4 0x2b98a58cfc3b in XParseColor () from /usr/lib/libX11.so.6 #5 0x0042c747 in AllocateAnsiColor (pTerm=0x595420, res=0x595778, spec=0x443ca5 "white") at ./misc.c:1454 #6 0x0042c8e3 in xtermGetColorRes (res=0x595778) at ./misc.c:1484 #7 0x0040c16d in SGR_Foreground (color=15) at ./charproc.c:805 #8 0x0040c4f4 in setExtendedFG () at ./charproc.c:881 #9 0x0040e101 in doparsing (c=109, sp=0x5615e0) at ./charproc.c:1869 #10 0x0040f9a0 in VTparse () at ./charproc.c:2785 #11 0x00413687 in VTRun () at ./charproc.c:4737 #12 0x004246df in main (argc=0, argv=0x7fff05c8d380) at ./main.c:2354 (gdb) kill Kill the program being debugged? (u or n) y tarting program: /home/slimak/kodowanie/got/debian/xterm-210/xterm (xterm started, i started mc from xterm it got frozen a bit later, i hit ctrl-c in gdb) Program received signal SIGINT, Interrupt. 0x2bcc1c8f in poll () from /lib/libc.so.6 (gdb) bt #0 0x2bcc1c8f in poll () from /lib/libc.so.6 #1 0x2b8e6d2f in XProcessInternalConnection () from /usr/lib/libX11.so.6 #2 0x2b8e7142 in _XRead () from /usr/lib/libX11.so.6 #3 0x2b8e7b81 in _XReply () from /usr/lib/libX11.so.6 #4 0x2b8d4c3b in XParseColor () from /usr/lib/libX11.so.6 #5 0x0042c747 in AllocateAnsiColor (pTerm=0x595420, res=0x5956d0, spec=0x443c05 "gray50") at ./misc.c:1454 #6 0x0042c8e3 in xtermGetColorRes (res=0x5956d0) at ./misc.c:1484 #7 0x0040c16d in SGR_Foreground (color=8) at ./charproc.c:805 #8 0x0040c4f4 in setExtendedFG () at ./charproc.c:881 #9 0x0040e101 in doparsing (c=109, sp=0x5615e0) at ./charproc.c:1869 #10 0x0040f9a0 in VTparse () at ./charproc.c:2785 #11 0x00413687 in VTRun () at ./charproc.c:4737 #12 0x004246df in main (argc=0, argv=0x7fff55c88370) at ./main.c:2354 (gdb) kill Kill the program being debugged? (y or n) y (gdb) run Starting program: /home/slimak/kodowanie/got/debian/xterm-210/xterm (xterm started, i run mc in it, it does no freeze this time, but i interrupt it anyway ;) Program received signal SIGINT, Interrupt. 0x2b8583743a45 in select () from /lib/libc.so.6 (gdb) bt #0 0x2b8583743a45 in select () from /lib/libc.so.6 #1 0x0041027c in in_put () at ./charproc.c:3190 #2 0x0041036c in doinput () at ./charproc.c:3222 #3 0x0040f993 in VTparse () at ./charproc.c:2785 #4 0x00413687 in VTRun () at ./charproc.c:4737 #5 0x004246df in main (argc=0, argv=0x7fff282058f0) at ./main.c:2354 (gdb) kill Kill the program being debugged? (y or n) y (gdb) > Doing that would give more insight into the problem - to see whether it's > an X library problem, or whether xterm's gotten into some state that I > could fix. What next? Regards Jan Górski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329901: xterm freezes when starting mc
On Tue, Oct 31, 2006 at 12:21:35AM +0100, Jan Gorski wrote: > On Sun, 25 Sep 2005 at 12:32:07 -0400, Thomas Dickey wrote: > > On Sun, Sep 25, 2005 at 04:50:14PM +0200, Jan Gorski wrote: > > > On Sat, 24 Sep 2005 at 19:25:52 -0400, Thomas Dickey wrote: > > > > (That would be "configure --enable-trace --enable-wide-chars > > > > --enable-luit", > > > > and the executable produces Trace-parent.out and Trace-child.out) > > > > > > Well, I've run it. Traces are in > > > http://slimak.info/~slimak/traces.tar.bz2 if > > > you want to look at them. All hangs end with this line > > > > thanks (got a copy for reading) sorry - I should have followed up, hadn't seen much to report > For some time I was using xfce4-terminal and xfce4wm to avoid this bug (and > another one, 329916). At least month ago I gave a try to fvwm again, and it > was > working --- till last upgrade :). Now I have checkd it in few configurations, > and it seems, that both bugs depend on xinerama(1)... Bug 329916 is a bit > upredictible, and sometimes it takes a moment till it appears, but this bug is > easier to reproduce, so maybe somebody can tell me what else can be done to > find > out what happens? If you could reproduce it with a copy of xterm built with debug code, then it's possible that you could attach it with gdb from another window and see where it's hanging. You wouldn't need the setgid mode on the executable, since it's unlikely that the utmp code is involved. Doing that would give more insight into the problem - to see whether it's an X library problem, or whether xterm's gotten into some state that I could fix. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpNn2nMqRXSp.pgp Description: PGP signature
Bug#329901: xterm freezes when starting mc
On Sun, 25 Sep 2005 at 12:32:07 -0400, Thomas Dickey wrote: > On Sun, Sep 25, 2005 at 04:50:14PM +0200, Jan Gorski wrote: > > On Sat, 24 Sep 2005 at 19:25:52 -0400, Thomas Dickey wrote: > > > (That would be "configure --enable-trace --enable-wide-chars > > > --enable-luit", > > > and the executable produces Trace-parent.out and Trace-child.out) > > > > Well, I've run it. Traces are in http://slimak.info/~slimak/traces.tar.bz2 > > if > > you want to look at them. All hangs end with this line > > thanks (got a copy for reading) For some time I was using xfce4-terminal and xfce4wm to avoid this bug (and another one, 329916). At least month ago I gave a try to fvwm again, and it was working --- till last upgrade :). Now I have checkd it in few configurations, and it seems, that both bugs depend on xinerama(1)... Bug 329916 is a bit upredictible, and sometimes it takes a moment till it appears, but this bug is easier to reproduce, so maybe somebody can tell me what else can be done to find out what happens? Cheers Jan Górski (1) adding Option "Xinerama" to sigle monitor configuration does not trigger problems, so maybe not xinerama, but something else connected with using two monitors... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329901: xterm freezes when starting mc
On Sun, Sep 25, 2005 at 04:50:14PM +0200, Jan Gorski wrote: > On Sat, 24 Sep 2005 at 19:25:52 -0400, Thomas Dickey wrote: > > (That would be "configure --enable-trace --enable-wide-chars --enable-luit", > > and the executable produces Trace-parent.out and Trace-child.out) > > Well, I've run it. Traces are in http://slimak.info/~slimak/traces.tar.bz2 if > you want to look at them. All hangs end with this line thanks (got a copy for reading) > xtermGetColorRes for Acolors[x] > > with different x. > > I've noticed one more thing --- with default font mc starts without problems. > I use *VT100*font: -xos4-terminus-bold-r-normal--24-240-72-72-c-120-iso10646-1 > > > Other than that - attaching gdb to the xterm process and doing a bt (stack > > trace) should show where it is executing. > > #0 0xb7c4cf58 in select () from /lib/tls/libc.so.6 > #1 0xb7ed962a in _XEnq () from /usr/X11R6/lib/libX11.so.6 > #2 0xb7ed9a3e in _XRead () from /usr/X11R6/lib/libX11.so.6 > #3 0xb7edaa2a in _XReply () from /usr/X11R6/lib/libX11.so.6 > #4 0xb7ecb3c6 in XParseColor () from /usr/X11R6/lib/libX11.so.6 > #5 0x0806a605 in AllocateAnsiColor (pTerm=0x80c2490, res=0x80c2628, > spec=0x80c062c "yellow") at ./misc.c:1421 > #6 0x0806a743 in xtermGetColorRes (res=0x80c2628) at ./misc.c:1451 > #7 0x08050ff3 in SGR_Foreground (color=11) at ./charproc.c:805 > #8 0x08051189 in setExtendedFG () at ./charproc.c:881 > #9 0x08057f32 in doparsing (c=Variable "c" is not available.) > at ./charproc.c:1915 > #10 0x08059621 in VTparse () at ./charproc.c:2770 > #11 0x08059725 in VTRun () at ./charproc.c:4667 > #12 0x08066be5 in main (argc=0, argv=0xbfaaf288) at ./main.c:2291 > > Does it make things clearer? That sounds like some useful information. xterm loads the color information for resource-values once - the first time they're used. But you're running mc twice, and it's allocating colors. iirc, mc uses yellow in each screen. So it sounds as if "once" is not correct (I'll have to review that and see if I can guess why). Why it would break for a particular font - I can't guess (though I suppose it's possible that some logic error with fonts could cause the program to modify the resource table - that's only speculation). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpcS3RA7WhMt.pgp Description: PGP signature
Bug#329901: xterm freezes when starting mc
On Sat, 24 Sep 2005 at 19:25:52 -0400, Thomas Dickey wrote: > (That would be "configure --enable-trace --enable-wide-chars --enable-luit", > and the executable produces Trace-parent.out and Trace-child.out) Well, I've run it. Traces are in http://slimak.info/~slimak/traces.tar.bz2 if you want to look at them. All hangs end with this line xtermGetColorRes for Acolors[x] with different x. I've noticed one more thing --- with default font mc starts without problems. I use *VT100*font: -xos4-terminus-bold-r-normal--24-240-72-72-c-120-iso10646-1 > Other than that - attaching gdb to the xterm process and doing a bt (stack > trace) should show where it is executing. #0 0xb7c4cf58 in select () from /lib/tls/libc.so.6 #1 0xb7ed962a in _XEnq () from /usr/X11R6/lib/libX11.so.6 #2 0xb7ed9a3e in _XRead () from /usr/X11R6/lib/libX11.so.6 #3 0xb7edaa2a in _XReply () from /usr/X11R6/lib/libX11.so.6 #4 0xb7ecb3c6 in XParseColor () from /usr/X11R6/lib/libX11.so.6 #5 0x0806a605 in AllocateAnsiColor (pTerm=0x80c2490, res=0x80c2628, spec=0x80c062c "yellow") at ./misc.c:1421 #6 0x0806a743 in xtermGetColorRes (res=0x80c2628) at ./misc.c:1451 #7 0x08050ff3 in SGR_Foreground (color=11) at ./charproc.c:805 #8 0x08051189 in setExtendedFG () at ./charproc.c:881 #9 0x08057f32 in doparsing (c=Variable "c" is not available.) at ./charproc.c:1915 #10 0x08059621 in VTparse () at ./charproc.c:2770 #11 0x08059725 in VTRun () at ./charproc.c:4667 #12 0x08066be5 in main (argc=0, argv=0xbfaaf288) at ./main.c:2291 Does it make things clearer? Pozdrawiam Slimak (na krawędzi) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329901: xterm freezes when starting mc
On Sun, Sep 25, 2005 at 12:40:03AM +0200, Jan Gorski wrote: > On Sat, 24 Sep 2005 at 15:21:54 -0400, Thomas Dickey wrote: > > If you can kill the mc process from another xterm without killing the xterm, > > it is likely that the problem lies in mc rather than xterm. > > I can kill mc, but xterm is still frozen. Similar thing happens with mutt. > BTW, > is it possible and not considered a bug, that application can leave xterm in > frozen state even after it has been killed? I cannot even raise any menu with > ctrl click. How can I investigate this? That does sound like a bug. But (I've not updated for about a month), a quick check doesn't show it breaking for me, given the locale, etc. Since I don't recall an xterm bug that looks like this, I'm thinking it is in the X libraries (though it's still possible that it's xterm of course). If I were seeing the bug, I'd try compiling xterm and running it with its debug-trace, to see if there was some useful information - to point to an xterm bug. (That would be "configure --enable-trace --enable-wide-chars --enable-luit", and the executable produces Trace-parent.out and Trace-child.out) Other than that - attaching gdb to the xterm process and doing a bt (stack trace) should show where it is executing. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpTn4zCgaQjX.pgp Description: PGP signature
Bug#329901: xterm freezes when starting mc
On Sat, 24 Sep 2005 at 15:21:54 -0400, Thomas Dickey wrote: > If you can kill the mc process from another xterm without killing the xterm, > it is likely that the problem lies in mc rather than xterm. I can kill mc, but xterm is still frozen. Similar thing happens with mutt. BTW, is it possible and not considered a bug, that application can leave xterm in frozen state even after it has been killed? I cannot even raise any menu with ctrl click. How can I investigate this? Pozdrawiam Slimak (na krawędzi) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329901: xterm freezes when starting mc
On Sat, Sep 24, 2005 at 12:20:05PM +0200, Jan Gorski wrote: > Package: xterm > Version: 6.8.2.dfsg.1-7 > Severity: normal > > > I've recently set LC_CTYPE to pl_PL.UTF-8. Now after starting X first and > second > run of mc in xterm is unsuccesfull. > > Run 1. Only first line (menubar) is renderd. > Run 2. First line and 39 characters of second line are visible. > Run 3. Not all lines are visible, but xterm does not freeze and ^L repaints > window. If you can kill the mc process from another xterm without killing the xterm, it is likely that the problem lies in mc rather than xterm. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpfMnk8EsHIE.pgp Description: PGP signature
Bug#329901: xterm freezes when starting mc
Package: xterm Version: 6.8.2.dfsg.1-7 Severity: normal I've recently set LC_CTYPE to pl_PL.UTF-8. Now after starting X first and second run of mc in xterm is unsuccesfull. Run 1. Only first line (menubar) is renderd. Run 2. First line and 39 characters of second line are visible. Run 3. Not all lines are visible, but xterm does not freeze and ^L repaints window. Pozdrawiam Slimak (na krawędzi) -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (800, 'testing'), (500, 'stable'), (70, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12dwapiii.1.0 Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Versions of packages xterm depends on: ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libexpat1 1.95.8-3 XML parsing C library - runtime li ii libfontconfig12.3.2-1generic font configuration library ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib ii libice6 6.8.2.dfsg.1-7 Inter-Client Exchange library ii libncurses5 5.4-9 Shared libraries for terminal hand ii libsm66.8.2.dfsg.1-7 X Window System Session Management ii libxaw8 6.8.2.dfsg.1-7 X Athena widget set library ii libxext6 6.8.2.dfsg.1-7 X Window System miscellaneous exte ii libxft2 2.1.7-1FreeType-based font drawing librar ii libxmu6 6.8.2.dfsg.1-7 X Window System miscellaneous util ii libxp66.8.2.dfsg.1-7 X Window System printing extension ii libxpm4 6.8.2.dfsg.1-7 X pixmap library ii libxrender1 1:0.9.0-2 X Rendering Extension client libra ii libxt66.8.2.dfsg.1-7 X Toolkit Intrinsics ii xlibs 6.8.2.dfsg.1-7 X Window System client libraries m ii xlibs-data6.8.2.dfsg.1-7 X Window System client data Versions of packages xterm recommends: ii xutils6.8.2.dfsg.1-7 X Window System utility programs -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
