Package: kinput2-wnn
Version: 3.1-10.3
Severity: normal
Tags: upstream
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***
* What led up to the situation?
I was running kinput2-wnn (built from source: kinput2 (3.1-10.3)
unstable;
urgency=low) under valgrind to catch memory related errors.
Then I notice that kinput2-wnn accesses FREEed area :-(
* What exactly did you do (or not do) that was effective (or
ineffective)?
I was typing Japanese text using kinput2-wnn into thunderbird build,
then
thunderbird crashed due to its own error.
When this happened, I noticed that valgrind printed the log messages
reporting
that kinput2-wnn accessed freed memory area.
* What was the outcome of this action?
kinput2-wnn accessed freed memory area (that contains junk.)
* What outcome did you expect instead?
kinput2-wnn should not access freed memory area.
*** End of the template - remove these lines ***
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-2-686-pae (SMP w/1 CPU core)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages kinput2-wnn depends on:
ii debconf [debconf-2.0] 1.5.46
ii freewnn-common 1.1.1~a021+cvs20100325-6
ii kinput2-common 3.1-10.3
ii libc6 2.13-35
ii libice6 2:1.0.8-2
ii libsm6 2:1.2.1-2
ii libwnn6-1 1.0.0-14.2+b1
ii libx11-6 2:1.5.0-1
ii libxaw7 2:1.0.10-2
ii libxext6 2:1.3.1-2
ii libxmu6 2:1.1.1-1
ii libxpm4 1:3.5.10-1
ii libxt6 1:1.1.3-1
Versions of packages kinput2-wnn recommends:
ii xfonts-base 1:1.0.3
Versions of packages kinput2-wnn suggests:
ii freewnn-jserver 1.1.1~a021+cvs20100325-6
-- debconf information:
shared/kinput2/wnn/keybindings: Egg
*** /tmp/kinput2-free-bug-log.txt
...
Looks that kinput2-wnn tries to access Freed Area(!)
[after a TCP connection is disconnected!]
This happened when TB suddenly died when I tried to show version
number using [help] -> [about]. 20th Oct, 2012
==30391== by 0x416420E: XtFree (in
/usr/lib/i386-linux-gnu/libXt.so.6.0.0)
==30391== by 0x806E5FA: IMProcessQueue (imdispatch.c:471)
==30391== by 0x8070A76: xBrokenPipe (imxport.c:347)
==30391== by 0x805DC05: XAEHandler (asyncerr.c:153)
==30391== by 0x42384A2: _XError (XlibInt.c:1583)
==30391== by 0x423535C: handle_error (xcb_io.c:212)
==30391== by 0x42353B6: handle_response (xcb_io.c:324)
==30391== by 0x4235E97: _XEventsQueued (xcb_io.c:363)
==30391== by 0x4235F29: _XFlush (xcb_io.c:513)
==30391== by 0x4216EB0: XFlush (Flush.c:39)
==30391== by 0x8070827: xFlush (imxport.c:407)
==30391==
==30391== Invalid read of size 4
==30391== at 0x807060E: xFlush (imxport.c:366)
==30391== by 0x806E63F: IMProcessQueue (imdispatch.c:457)
==30391== by 0x8070B5D: xinput (imxport.c:298)
==30391== by 0x4349E45: (below main) (libc-start.c:228)
==30391== Address 0x4d0144c is 28 bytes inside a block of size 600 free'd
==30391== at 0x402618D: free (vg_replace_malloc.c:446)
==30391== by 0x416420E: XtFree (in
/usr/lib/i386-linux-gnu/libXt.so.6.0.0)
==30391== by 0x806E5FA: IMProcessQueue (imdispatch.c:471)
==30391== by 0x8070A76: xBrokenPipe (imxport.c:347)
==30391== by 0x805DC05: XAEHandler (asyncerr.c:153)
==30391== by 0x42384A2: _XError (XlibInt.c:1583)
==30391== by 0x423535C: handle_error (xcb_io.c:212)
==30391== by 0x42353B6: handle_response (xcb_io.c:324)
==30391== by 0x4235E97: _XEventsQueued (xcb_io.c:363)
==30391== by 0x4235F29: _XFlush (xcb_io.c:513)
==30391== by 0x4216EB0: XFlush (Flush.c:39)
==30391== by 0x8070827: xFlush (imxport.c:407)
==30391== Invalid read of size 4
==30391== at 0x8070614: xFlush (imxport.c:371)
==30391== by 0x806E63F: IMProcessQueue (imdispatch.c:457)
==30391== by 0x8070B5D: xinput (imxport.c:298)
==30391== by 0x4349E45: (below main) (libc-start.c:228)
==30391== Address 0x4d01570 is 320 bytes inside a block of size 600 free'd
==30391== at 0x402618D: free (vg_replace_malloc.c:446)
==30391== by 0x416420E: XtFree (in
/usr/lib/i386-linux-gnu/libXt.so.6.0.0)
==30391== by 0x806E5FA: IMProcessQueue (imdispatch.c:471)
==30391== by 0x8070A76: xBrokenPipe (imxport.c:347)
==30391== by 0x805DC05: XAEHandler (asyncerr.c:153)
==30391== by 0x42384A2: _XError (XlibInt.c:1583)
==30391== by 0x423535C: handle_error (xcb_io.c:212)
==30391== by 0x42353B6: handle_response (xcb_io.c:324)
==30391== by 0x4235E97: _XEventsQueued (xcb_io.c:363)
==30391== by 0x4235F29: _XFlush (xcb_io.c:513)
==30391== by 0x4216EB0: XFlush (Flush.c:39)
==30391== by 0x8070827: xFlush (imxport.c:407)
==30391== Invalid read of size 4
==30391== at 0x807061A: xFlush (imxport.c:371)
==30391== by 0x806E63F: IMProcessQueue (imdispatch.c:457)
==30391== by 0x8070B5D: xinput (imxport.c:298)
==30391== by 0x4349E45: (below main) (libc-start.c:228)
==30391== Address 0x4d0156c is 316 bytes inside a block of size 600 free'd
==30391== at 0x402618D: free (vg_replace_malloc.c:446)
==30391== by 0x416420E: XtFree (in
/usr/lib/i386-linux-gnu/libXt.so.6.0.0)
==30391== by 0x806E5FA: IMProcessQueue (imdispatch.c:471)
==30391== by 0x8070A76: xBrokenPipe (imxport.c:347)
==30391== by 0x805DC05: XAEHandler (asyncerr.c:153)
==30391== by 0x42384A2: _XError (XlibInt.c:1583)
==30391== by 0x423535C: handle_error (xcb_io.c:212)
==30391== by 0x42353B6: handle_response (xcb_io.c:324)
==30391== by 0x4235E97: _XEventsQueued (xcb_io.c:363)
==30391== by 0x4235F29: _XFlush (xcb_io.c:513)
==30391== by 0x4216EB0: XFlush (Flush.c:39)
==30391== by 0x8070827: xFlush (imxport.c:407)
==30391==
GetProp:98: nbytes=0
GetProp:98: nbytes=0
GetProp:98: nbytes=0
I tried to re-capture the similar messages, but this seems highly
timing- and
history- dependent and could not.
But looking at the code, I suspect there is flaw in the logic about
handling events/messages for abruptly shutdown connections.
(Maybe kinput2-wnn is not protecting the list structure from the asyncronous
handling. Note the invokcation of XAEHandler which eventually invoked free.)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
