#28 keyboard & X complete lockup


I like mlterm because it has nice support for
international characters, a feature I find missing in
many other terminal programs. The image support is nice
and your many command line config options are great.

While testing today, I have had 2 complete system
lockups. In an mlterm, I sometimes open a man page and
while searching in there after hitting the / key and
typing a string, the whole display & keyboard locks
down tight. I guess the problem may be that I
inadvertently hit another key--the / key is down by
CTL and ALT. None of the usual unlocking tricks, like
ALT-CTL-Backspace or CTL-q have any effect. I am able
to log into the computer from another one and kill the
mlterms, but the computer does not become unstuck. I
can force a re-start of the display manager (gdm) and
that will kill all open programs.

This has happened twice since I built the RPM using the
spec file you provide with mlterm-2.9.2-1.

If you think that running mlterm under gdb might help,
I can do that. I fear that would be a waste of time
because the system lock up would prevent me from
running the backtrace.

I SUSPECT (wild guess!) that the problem has something
to do with the access to gzipped man pages? The
problem only happens when I'm running man and searching

I am starting mlterm like this

mlterm -p /usr/local/share/Termpics/Xmas2003_b2.jpg
--geometry=80x24 -w 14 -n -f gray70 -r 40 -H 40 -b
black -O none

with various backgrounds.

Now, about my computer

This is a Dell Latitude D800 running Fedora Core 4
Linux with all of the newest updates. Kernel
version=kernel-2.6.14-1.1637_FC4. The WindowManager is
Window Maker 0.92. The video card is an Nvidia mobile
GeForce and the proprietary Nvidia video drivers and
kernel module is being used.

I've used this computer very often and never had a lock
up until I tried mlterm this morning.

I can make available a copy of the compiled version of
the mlterm RPM that I built from your source package's
spec file if that might help.

$ ldd /usr/bin/mlterm
linux-gate.so.1 => (0x007c6000)
libImlib.so.11 => /usr/lib/libImlib.so.11
libjpeg.so.62 => /usr/lib/libjpeg.so.62
libtiff.so.3 => /usr/lib/libtiff.so.3 (0x038f5000)
libungif.so.4 => /usr/lib/libungif.so.4
libpng12.so.0 => /usr/lib/libpng12.so.0
libz.so.1 => /usr/lib/libz.so.1 (0x004da000)
libm.so.6 => /lib/libm.so.6 (0x004ad000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6
libSM.so.6 => /usr/X11R6/lib/libSM.so.6
libICE.so.6 => /usr/X11R6/lib/libICE.so.6
libX11.so.6 => /usr/X11R6/lib/libX11.so.6
libmkf.so.13 => /usr/lib/libmkf.so.13 (0x00cfa000)
libkik.so.10 => /usr/lib/libkik.so.10 (0x00aef000)
libdl.so.2 => /lib/libdl.so.2 (0x004d4000)
libutil.so.1 => /lib/libutil.so.1 (0x036e2000)
libc.so.6 => /lib/libc.so.6 (0x00382000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00c27000)
/lib/ld-linux.so.2 (0x00364000)


  • MINAMI Hirokazu

    MINAMI Hirokazu - 2005-11-25

    Logged In: YES

    If you are using pseudo-transparency with imlib,
    mlterm may be failing to unlock your X server properly.
    Would you try to use gdk-pixbuf library instead of imlib
    to render backgrounds?
    mlterm do not request to grab inputs in that case.
    So if the X server still hangs, it should be a problem
    inside of X.

    In any case, you can see what mlterm was doing by
    attaching gdb to the mlterm process.
    [logging in from another one]

    [check mlterm's process id]
    > ps x |grep mlterm
    1234 /usr/bin/mlterm

    [attach gdb to the process and take a backtrace]
    >gdb /usr/bin/mlterm 1234
    gdb> bt

    And, as a workaround, you may be able to ungrab
    locks on keyboard/pointer etc. by activating
    coressponding key sequences in xorg.conf.
    (enable "AllowDeactivateGrabs").

  • MINAMI Hirokazu

    MINAMI Hirokazu - 2005-11-25
    • assigned_to: nobody --> h_minami
  • MINAMI Hirokazu

    MINAMI Hirokazu - 2006-05-30
    • priority: 5 --> 1
    • status: open --> pending-works-for-me
  • SourceForge Robot

    Logged In: YES

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

  • SourceForge Robot

    • status: pending-works-for-me --> closed-works-for-me

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks