Mark Purcell wrote:
> On Tuesday 21 October 2008 20:55:24 ishikawa wrote:
>> Severity: serious
>> Justification: 2
>>
>> (I am afraid I screwed up the Severity and Justification code. Please
>> feel free to modify them.)
>
> ishikawa,
>
> Did you indeed intend to set severity to serious? We are now tracking this
> on
> the release critical bugs for lenny.
Dear Mark Purcell,
Please feel free to change this to a lesser Severity/Justification code
which makes this to a normal bug (that affects users of this package.
And that this package is unusable and hard to find the cause if a
misconfiguration causes a double invocation of kinput2-wnn, it seems.
Read on.)
This was the first time in years that I used
bug reporting program and I screwed up and didn't know how to
go back and fix.
>
>> When I was using kinput2-wnn from ice-weasel, kinput2-wnn crashed.
>
> Can you tell us a little more about what you were doing at the time, is it
> repeatable, does it make kinput2-wnn unusable, or does it just happen on an
> occasional basis?
This is repeatable.
Each time input is attmpted using kinput2-wnn to ice-weasel input field
such as Google search bar, ice-weasel crashed.
However, I found out later that this seemed to be
caused a particular combination of environment.
- Note there is a bug report that mentions that this daemon-like
service, kinput2-wnn,
for Japanese input can be invoked multiple times, but this should not
be done. So a locking is desired to prevent the second invocation to
fail.
- Indeed, in my case, I was invoking this program from my own x11
session initialization
script (which worked fine on my home PC. I will come back to this
later in this e-mail.) as well as the automatic
invocation done by a script under /etc/X11/ which obviously
is done by gdm.
As a result, there are multiple instances of kinput2-wnn running.
One from the gdm-initiated xinit.d/ script, and the other
one from my own startup routine that I invoke immediately
after X starts up.
This multiple invocation is obviously a culprit.
When I removed one of the instances (by kill PID),
ice-weasel no longer crashed when I attemped Japanese input.
(Japanese input is usually initiated by hitting SHIFT+SPACE.
This key combination can be changed by .Xresource file, or something.)
But for confirmation purpose,
if I invoke another kinput2-wnn instance again from an terminal window
in the same X session, again ice-weasel began crashing when I try
to input Japanese by hitting SHIFT+SPACE.
So I am fairly certain that the multiple invocations cause
this problem and this was repeatable on my PC.
CAUTION: This crashing may be highly-dependent on
the particular version of ice-weasel or firefox browser, and input
libraries.
Now, this multiple invocation would have been
prevented, had this locking feature suggested by
another bug report had been implemented
to prevent the second and
subsequent invocation from succeeding.
This is in one of the bug report of kinput2-wnn.
There seem to be some kind of race (?).
Then one may wonder this bug reporter (me) mentions that
a similar script is used on a different PC where it doesn't seem
to cause a problem. Why? Actually I wondered why loudly.
I found out on the PC where this problem had not been observed for a
while, there *ARE* instances of kinput2-wnn programs running.
However, on that PC, I am using a commercial wnn6 version of library
as opposed to wnn4 (in Free Wnn4 support).
This may explain the absence of errors on that computer.
Maybe the library has a proper handling of races caused by
the multiple instances of the same program.
(For that matter, the Japanese server daemon that uses
dictionary, namely jserver, is also a commercial version
on that computer. So this may also explain the absence
of the problem on that computer.)
cf. The following is the status on the other PC that runs Debian
distribution, where the problem was not observed for quite a
while.
[EMAIL PROTECTED]
ps -aef | grep kinput; which kinput2; ls -l /usr/bin/kinput2; ls -l
/etc/alternatives/kinput2; ldd /usr/bin/kinput2-wnn
ishikawa 4088 3896 0 Oct31 ? 00:00:00 /usr/bin/kinput2-wnn -xim
ishikawa 4272 1 0 Oct31 pts/0 00:00:00 sh -vx
/home/ishikawa/kinput2.sh
ishikawa 4278 4272 0 Oct31 pts/0 00:00:00 kinput2 -jserver
localhost -wnn -wnnenvrc6 /usr/local/lib/wnn6/ja_JP/wnnenvrc
ishikawa 10948 4223 0 00:46 pts/0 00:00:00 grep kinput
Note that there are two instances:
kinput2 and kinput2-wnn. They are actually the same.
ls -l /usr/bin/kinput2
lrwxrwxrwx 1 root root 25 2008-04-22 23:31 /usr/bin/kinput2 ->
/etc/alternatives/kinput2*
ls -l /etc/alternatives/kinput2
lrwxrwxrwx 1 root root 20 2008-04-22 23:31 /etc/alternatives/kinput2 ->
/usr/bin/kinput2-wnn*
So /usr/bin/kinput2-wnn and /usr/bin/kinput2 are actually the same program.
Library used:
ldd /usr/bin/kinput2-wnn
linux-gate.so.1 => (0xffffe000)
libwnn6.so.1 => /usr/lib/libwnn6.so.1 (0xb7ec8000)
This above library is from the commercial version of Wnn
input server.
I suspect that this one has a proper locking that prevents
the kind of problems that were observed on my other PC
where wnn4 support library was available.
libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb7e96000)
libXaw.so.7 => /usr/lib/libXaw.so.7 (0xb7e3b000)
libXmu.so.6 => /usr/lib/libXmu.so.6 (0xb7e26000)
libXt.so.6 => /usr/lib/libXt.so.6 (0xb7dd6000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xb7dce000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xb7db7000)
libXpm.so.4 => /usr/lib/libXpm.so.4 (0xb7da7000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb7d98000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7ca9000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7b4e000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7b4b000)
libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb7b49000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb7b30000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7b2c000)
/lib/ld-linux.so.2 (0xb7f32000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7b27000)
[EMAIL PROTECTED]
> Keita, I see that you haven't uploaded a version of this package since 2006
> and that was a few debconf translations.
>
> Are you in a position to review your package against this bug report?
>
> Mark
>
Thank you again for your follow-up despite my errorneous code given my
initial mistake.
I will try to re-create test conditions on my different PCs.
Today is Friday evening, but unfortunately, coming Monday is
a national holiday in Japan, and the particular PC where the
crashing behavior was observed is the in the locked office. Until
Tuesday, I can't touch it.
In the meantime, I can create test conditions on a home PC which
uses a commercial wnn6 support library and so can produce a comparative
report if necessary (albeit the lack of the other side that uses free
wnn4 support library. That has to wait until Next Tuesday.)
TIA
Chiaki Ishikawa
--
int main(void){int j=2008;/*(c)2008 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="b>qtCIuqivb,[EMAIL PROTECTED]"tqkvv is>dnamz";
while(*i)((j+=(int)strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
