tclkit loses its keyboard response? SuSE 10.2 & KDE
C. Andrews Lavarre
I am using Notebook (http://notebook.wjduquette.com/) compiled as a
starkit running KDE on SuSE 10.2 (also on SuSE 10.1) on another
machine. After a while they keyboard dies, but only in the Notebook
application. It operates normally in the rest of the OS with other
applications. restarting X, KDE, indeed rebooting, none of these restore
the keyboard. It died on Thursday, I reinstalled the entire OS
(fortunately still in the early stages of a new machine install) and
that restored it for a few hours, but now the keyboard has died again,
but again only in Notebook.
I've googled and searched this newsgroup, I've searched for some hidden
.tclrc file without success. There is a keys.tcl file in the source, but
this only addresses Ctrl+F and Ctrl+G, while the really important keys
are Ctrl+S and Ctrl+E.
Thanks in advance.
Kind regards,
Andy
Michael Schlenker
methods in some Tcl versions.
1. Which version of Tcl do you use to run the app?
2. Do you have the SCIM input package installed on suse?
Michael
Alexandre Ferrieux
>
> I am using Notebook (http://notebook.wjduquette.com/) compiled as a
> starkit running KDE on SuSE 10.2 (also on SuSE 10.1) on another
> machine. After a while they keyboard dies, but only in the Notebook
> application. It operates normally in the rest of the OS with other
> applications. restarting X, KDE, indeed rebooting, none of these restore
> the keyboard.
Such stickiness is really weird.
Surviving reboots means it's stored in some file.
Since it afflicts only one application, it seems to rule out the X
server.
(To verify this, once the bug is here, try launching the app with a
different $DISPLAY. It should behave the same on the 2nd display).
Then I'd use strace to see what files the app opens, then try to spot
one more recent than the bug onset...
-Alex
C. Andrews Lavarre
> Not sure if it is related, but there were some problems with input
> methods in some Tcl versions.
>
> 1. Which version of Tcl do you use to run the app?
Hmm. Not sure how to find that out. The starkit is 2.1.3
locate tcl/tk returns
/usr/share/tcl/tk8.4
as a directory with lots of stuff.
> 2. Do you have the SCIM input package installed on suse?
Apparently so: locate scim returns
/usr/lib/scim-1.0/1.4.0 as a directory
Thank you for your time.
Kind regards, Andy
C. Andrews Lavarre
> Such stickiness is really weird.
:-(
> Surviving reboots means it's stored in some file.
Concur. I've looked in ~ for .*rc files, without success. Don't know
where the tclrc files might be... Needless to say,
locate tclrc
returns an null string.
> Since it afflicts only one application, it seems to rule out the X
> server.
> (To verify this, once the bug is here, try launching the app with a
> different $DISPLAY. It should behave the same on the 2nd display).
Mmmm. Not sure what you mean. Change the display resolution?
I changed 1024x768 to 1024x600 and you are correct, it behaved the same:
still no keyboard input
> Then I'd use strace to see what files the app opens, then try to spot
> one more recent than the bug onset...
oooh. cool., something new to learn.
strace notebook2.1.3.kit > NBK_strace.txt
The readout is a bunch of gibberish. There is a stream of gibberish as
the app loads, then stops when the app is fully loaded. I key Ctrl+E,
which is supposed to convert the display to an editor, there is another
stream of gibberish, and it stops, then I do Ctrl+S, which is supposed
to close the editor and return to the main display, this gives another
stream of gibberish, which eventually stops.
Oddly this does not redirect; I see all the traces on the terminal, and
the target text file is a zero byte file. So I need to figure out how to
redirect the output into a save-able format for more analysis...
******Ooooh - even more interesting: when I start the basic starkit on
strace, there is no keyboard response. But if I tell it to open an
existing file, then the keyboard is restored!
It is starting to look like a permissions thing:
+ If I evoke the starkit AS ROOT the keyboard does not work, but if I
then tell it to open a file, the keyboard is restored in the newly
opened file. This is the same behaviour as noted on strace.
+ If I open the file directly as USER the keyboard is not available.
+ If I open the starkit as USER and then tell it to open a file then the
keyboard is not available.
So the keyboard only works if we first open the starkit AS ROOT then
invoke the data file AS ROOT.
I have checked the permissions on the starkit and the data file, they
are both UID andy:users and 0755. So there must be some permissions
problem with the tcl/tk files.
:-}
Il y a de progrès...
:-)
Très étrange. Beaucoup des weirdnesses.
Uwe Klein
> Alexandre, hello. Thank you.
>
>
>>Such stickiness is really weird.
>
>
> :-(
>
>
>>Surviving reboots means it's stored in some file.
>
>
> Concur. I've looked in ~ for .*rc files, without success. Don't know
> where the tclrc files might be... Needless to say,
>
> locate tclrc
>
> returns an null string.
>
>
>>Since it afflicts only one application, it seems to rule out the X
>>server.
>
>
>>(To verify this, once the bug is here, try launching the app with a
>>different $DISPLAY. It should behave the same on the 2nd display).
>
>
> Mmmm. Not sure what you mean. Change the display resolution?
>
> I changed 1024x768 to 1024x600 and you are correct, it behaved the same:
> still no keyboard input
>
>
>>Then I'd use strace to see what files the app opens, then try to spot
>>one more recent than the bug onset...
>
>
> oooh. cool., something new to learn.
>
> strace notebook2.1.3.kit > NBK_strace.txt
strace logs to stderr, use
either
strace notebook2.1.3.kit 2> NBK_strace.txt
or
strace -o NBK_strace.txt notebook2.1.3.kit
(you can select what type of system interaction to log
via commandline args, see the manpage).
<man strace>
NAME
strace - trace system calls and signals
SYNOPSIS
strace [ -dffhiqrtttTvxx ] [ -acolumn ] [ -eexpr ] ... [
-ofile ] [ -ppid ] ... [ -sstrsize ] [ -uusername ] [
-Evar=val ] ... [ -Evar ] ... [ command [ arg ... ] ]
strace -c [ -eexpr ] ... [ -Ooverhead ] [ -Ssortby ] [
command [ arg ... ] ]
DESCRIPTION
In the simplest case strace runs the specified command
until it exits. It intercepts and records the system
calls which are called by a process and the signals which
are received by a process. The name of each system call,
its arguments and its return value are printed on standard
error or to the file specified with the -o option.
</end>
uwe
C. Andrews Lavarre
> strace logs to stderr, use
> either
> strace notebook2.1.3.kit 2> NBK_strace.txt
> or
> strace -o NBK_strace.txt notebook2.1.3.kit
>
> (you can select what type of system interaction to log
> via commandline args, see the manpage).
Uwe, awesome.! Thank you. Now to do some analysis!
Kind regards, Andy
Alexandre Ferrieux
>
> > Since it afflicts only one application, it seems to rule out the X
> > server.
> > (To verify this, once the bug is here, try launching the app with a
> > different $DISPLAY. It should behave the same on the 2nd display).
>
> Mmmm. Not sure what you mean. Change the display resolution?
No. X is a network protocol, allowing you to transparently run a
graphical application on one CPU while displaying on another. This can
be done completely outside the app by setting the environment var
$DISPLAY to <other_host>:0.
For example, if you have X running on machine 'foo', from a shell on
machine 'bar' type
DISPLAY=foo:0 export DISPLAY (if you're under sh/bash)
setenv DISPLAY foo:0 (if you're under csh/tcsh)
then
notebook
(Usually, when you're all in one single machine, once X is started,
the xterm's from which you type commands inherit a $DISPLAY of :0 (or :
0.0), meaning localhost:0. That's why you never noticed :-)
Doing this, you hook up the given app (notebook here) to an entirely
different X server. So this test should definitely rule out the
possibility of a sticky bug stored in some X or KDE permanent settings
file.
> > Then I'd use strace to see what files the app opens, then try to spot
> > one more recent than the bug onset...
>
> oooh. cool., something new to learn.
OK. Sorry I was a bit terse.
As Uwe explains in his answer, strace writes to stderr by default.
To get back to stdout for display, storage, or filtering purposes, use
the shell's redirection facilities:
strace ... |& grep ... (in csh)
strace ... 2>&1 | grep ... (in sh)
Moreover, for this specific case, we're interested in the open() calls
only.
Strace has a built-in facility for filtering:
strace -e trace=open notebook
We can go even further in filtering by grepping out the failed open()
for files not found (ENOENT):
strace -e trace=open notebook |& grep -v ENOENT (I'm assuming csh)
I think the output of the above will be small enough for manual
inspection and even posting back here.
Then, for these opened files, give the last-modified date to identify
those which are consistent with the notion of "storing the bug".
> ******Ooooh - even more interesting: when I start the basic starkit on
> strace, there is no keyboard response. But if I tell it to open an
> existing file, then the keyboard is restored!
To analyze this part, I'd suggest using strace again, looking at what
happens when you type a key, in both situations. For this, just let
strace (without filtering options) write to stderr in a terminal
window, let all the init gibberish pass by, and concentrate just on
the new things displayed by one keystroke in the app's focus.
-Alex
C. Andrews Lavarre
> To analyze this part, I'd suggest using strace again, looking at what
> happens when you type a key, in both situations. For this, just let
> strace (without filtering options) write to stderr in a terminal
> window, let all the init gibberish pass by, and concentrate just on
> the new things displayed by one keystroke in the app's focus.
Alex, Uwe, thank you for the help. The problem is solved:
Examining strace.txt showed that a lot of files were not being found.
It Turns Out That (ITOT) I had the starkit in a directory that was not
in the default PATH. Moving the starkit to /usr/local/bin/develop (which
is exported in ~/.bashrc) solved the problem.
I would never have figured that out without strace. Thank you both.
Kind regards, Andy
Alexandre Ferrieux
>
> Examining strace.txt showed that a lot of files were not being found.
> in the default PATH. Moving the starkit to /usr/local/bin/develop (which
> is exported in ~/.bashrc) solved the problem.
I'm glad it solved your problem -- yet I'm a bit uneasy about why.
The PATH should only be used to look for executables, not even .so's.
If the starkit itself was outside the PATH, then you could have
started it only with an explicit pathname, but otherwise it should
have worked properly. The secundary files generated by its unpacking
process should be either virtual or extracted to a temporary directory
(for .so's), but in any case *not* sought by scanning $PATH either...
Maybe something else is at work. Could you list the offending files,
which are correctly found in your "fixed" setup ?
-Alex