Summary: | sys-process/iotop-0.2.1 - _curses.error: addstr() returned ERR | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | Current packages | Assignee: | Jeremy Olexa (darkside) (RETIRED) <darkside> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | cancellettopugno, divanorama, jer, kensington, klaas.decanniere |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 269924 | ||
Bug Blocks: | |||
Attachments: | Hex dump of the last lines recorded when iotop crashes |
Description
Toralf Förster
2008-10-02 13:57:25 UTC
Seems, this happens only if I compile wireshark from svn sources ... ?!? I'll be maintaining this now, looking at bugz next week. (In reply to comment #1) > Seems, this happens only if I compile wireshark from svn sources ... ?!? > How does that relate to iotop? I'm not sure what to do about this bug here. (In reply to comment #3) > (In reply to comment #1) > > Seems, this happens only if I compile wireshark from svn sources ... ?!? > > > > How does that relate to iotop? I'm not sure what to do about this bug here. > Presumably because compiling wireshark from svn produces a process with name/args that cause iotop to crash while trying to display. Thus reproducing the bug. My experience has been that emerging some packages will reproduce this, but I've not yet been attentive enough to catch it in the act. (emerge -e world resulted in occasionally checking back and generally finding iotop still running, but occasionally finding it crashed with the posted error output.) I did a couple of tests: iotop > /tmp/logfile.txt seem to run endlessly, while iotop | tee /tmp/logfile.txt eventually crashes, is it of some help the logfile so created? I'm asking because it 's quite bulky and maybe only its tail is of interest. Here are more programs which emerge output crashes iotop: kde-base/smoke-3.5.9 app-office/openoffice-3.0.0 sci-libs/fftw-3.2.1 dev-libs/DirectFB-1.2.7 There are two different workarounds, though: 1) append --color to emerge command 2) make output stop and restart with CTRL-S / CTRL-Q I don't know how the latter can be responsible for "cleaning" emerge output, but the fisrt makes sense. Seems this does occur after running it for a while, as recorded in GNU screen: PID USER DISK READ DISK WRITE SWAPIN IO> COMMAND 16235 jeroen 509.84 K/s 0 B/s 0.00 % 7.99 % nvidia-settings --load-c 16229 jeroen 3.89 K/s 0 B/s 0.00 % 0.76 % sh /home/jeroen/.xinitrc 1 root 0 B/s 0 B/s 0.00 % 0.00 % init [3] 2 root 0 B/s 0 B/s 0.00 % 0.00 % [kthreadd] 3 root 0 B/s 0 B/s 0.00 % 0.00 % [ksoftirqd/0] 4 root 0 B/s 0 B/s 0.00 % 0.00 % [watchdog/0] 5 root 0 B/s 0 B/s 0.00 % 0.00 % [events/0] 6 root 0 B/s 0 B/s 0.00 % 0.00 % [khelper] 1035 root 0 B/s 0 B/s 0.00 % 0.00 % [kjournald] 1029 root 0 B/s 0 B/s 0.00 % 0.00 % [rpciod/0] 20828 root 0 B/s 0 B/s 0.00 % 0.00 % turbotail -f -n 78 /var/ 11885 root 0 B/s 0 B/s 0.00 % 0.00 % python /usr/bin/iotop 4206 root 0 B/s 0 B/s 0.00 % 0.00 % dhcpcd -h astrid eth0 1140 root 0 B/s 0 B/s 0.00 % 0.00 % udevd --daemon 190 root 0 B/s 0 B/s 0.00 % 0.00 % [ksuspend_usbd] 121 root 0 B/s 0 B/s 0.00 % 0.00 % [kblockd/0] 124 root 0 B/s 0 B/s 0.00 % 0.00 % [kacpid] 5757 root 0 B/s 0 B/s 0.00 % 0.00 % sshd 16149 portage 0 B/s 0 B/s 0.00 % 0.00 % sh -c set -e; /usr/bin 17346 portage 0 B/s 0 B/s 0.00 % 0.00 % sh -c set -e; \ 5262 root 0 B/s 0 B/s 0.00 % 0.00 % crond 5145 root 0 B/s 0 B/s 0.00 % 0.00 % atd Traceback (most recent call last): B/s 0.00 % 0.00 % sshd: jeroen [priv] File "/usr/bin/iotop", line 16, in <module> main() File "//usr/lib/python2.5/site-packages/iotop/ui.py", line 249, in main curses.wrapper(run_iotop, options) File "/usr/lib/python2.5/curses/wrapper.py", line 44, in wrapper return func(stdscr, *args, **kwds) File "//usr/lib/python2.5/site-packages/iotop/ui.py", line 205, in run_iotop ui.run() File "//usr/lib/python2.5/site-packages/iotop/ui.py", line 95, in run self.process_list.duration) File "//usr/lib/python2.5/site-packages/iotop/ui.py", line 198, in refresh_display self.win.addstr(i + 2, 0, lines[i].encode('utf-8')) _curses.error: addstr() returned ERR Created attachment 190210 [details]
Hex dump of the last lines recorded when iotop crashes
There is a pattern. Two recurring offending lines:
3b 31 48 1b 5b 3f 32 35 68 1b 5b 72 1b 5b 3f 31 30 34 39 6c 0d 1b 3e
or
3b 31 48 1b 5b 3f 31 32 6c 1b 5b 3f 32 35 68 1b 5b 3f 31 30 34 39 6c 0d 1b 5b 3f 31 6c 1b 3e
BTW no program so far causes trouble to iotop but emerge.
This bug is fixed in upstream git commit 7915eb4181467e73b6bec5fa4c76bb6d4daf8979 and version 0.3. (In reply to comment #9) > This bug is fixed in upstream git commit > 7915eb4181467e73b6bec5fa4c76bb6d4daf8979 and version 0.3. > thx. We will leave this bug open until 0.3 is in the stable tree. 0.3 was *just* added to the tree now. I don't know if I have to open a new bug report... This is the crash with iotop-0.3 while compiling k3b in another shell: aemaeth ~ # iotop Traceback (most recent call last): File "/usr/bin/iotop", line 16, in <module> main() File "//usr/lib64/python2.5/site-packages/iotop/ui.py", line 361, in main main_loop() File "//usr/lib64/python2.5/site-packages/iotop/ui.py", line 351, in <lambda> main_loop = lambda: run_iotop(options) File "//usr/lib64/python2.5/site-packages/iotop/ui.py", line 267, in run_iotop return curses.wrapper(run_iotop_window, options) File "/usr/lib64/python2.5/curses/wrapper.py", line 44, in wrapper return func(stdscr, *args, **kwds) File "//usr/lib64/python2.5/site-packages/iotop/ui.py", line 261, in run_iotop_window ui.run() File "//usr/lib64/python2.5/site-packages/iotop/ui.py", line 112, in run self.process_list.duration) File "//usr/lib64/python2.5/site-packages/iotop/ui.py", line 248, in refresh_display self.win.addstr(i + 2, 0, lines[i].encode('utf-8')) _curses.error: addstr() returned ERR win:(79, 270) i:70 line:16954 be/5 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % sh -c failcom=\'exit 1\'; \\\nfor f in x $MAKEFLAGS; do \\\n case $f in \\\n *=* | --[!k]*);; \\\n *k*) failcom=\'fail=yes\';; \\\n esac; \\\ndone; \\\ndot_seen=no; \\\ntarget=`echo all-recursive | sed s/-recursive//`; \\\n It is just a little different but still isn't fixed. Same here for 0.3 Traceback (most recent call last): File "/usr/bin/iotop", line 16, in <module> main() File "//usr/lib64/python2.5/site-packages/iotop/ui.py", line 361, in main main_loop() File "//usr/lib64/python2.5/site-packages/iotop/ui.py", line 351, in <lambda> main_loop = lambda: run_iotop(options) File "//usr/lib64/python2.5/site-packages/iotop/ui.py", line 267, in run_iotop return curses.wrapper(run_iotop_window, options) File "/usr/lib64/python2.5/curses/wrapper.py", line 44, in wrapper return func(stdscr, *args, **kwds) File "//usr/lib64/python2.5/site-packages/iotop/ui.py", line 261, in run_iotop_window ui.run() File "//usr/lib64/python2.5/site-packages/iotop/ui.py", line 112, in run self.process_list.duration) File "//usr/lib64/python2.5/site-packages/iotop/ui.py", line 248, in refresh_display self.win.addstr(i + 2, 0, lines[i].encode('utf-8')) _curses.error: addstr() returned ERR win:(49, 133) i:46 line:20653 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % sh -c failcom=\'exit 1\'; \\\nfor f in x $MAKEFLAGS; do \\\n case $f in \\\n This also happened here with iotop-0.3.1 while compiling dev-libs/redland-1.0.9 $ iotop Traceback (most recent call last): File "/usr/bin/iotop", line 16, in <module> main() File "/usr/lib/python2.6/site-packages/iotop/ui.py", line 365, in main main_loop() File "/usr/lib/python2.6/site-packages/iotop/ui.py", line 355, in <lambda> main_loop = lambda: run_iotop(options) File "/usr/lib/python2.6/site-packages/iotop/ui.py", line 271, in run_iotop return curses.wrapper(run_iotop_window, options) File "/usr/lib/python2.6/curses/wrapper.py", line 44, in wrapper return func(stdscr, *args, **kwds) File "/usr/lib/python2.6/site-packages/iotop/ui.py", line 265, in run_iotop_window ui.run() File "/usr/lib/python2.6/site-packages/iotop/ui.py", line 110, in run self.process_list.duration) File "/usr/lib/python2.6/site-packages/iotop/ui.py", line 252, in refresh_display self.win.addstr(i + 2, 0, lines[i].encode('utf-8')) _curses.error: addstr() returned ERR win:(34, 117) i:30 line:25829 be/7 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % sh -c failcom=\'exit 1\'; \\\nfor f in x $MAKEFLAGS; do \\\n I tried compiling fftw and DirectFB with iotop-0.4 and it worked without any issues. these versions are gone from tree. current 0.4{,.1} isn't affected. |