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