Your message dated Sun, 18 Mar 2018 20:50:20 +0000
with message-id <[email protected]>
and subject line Bug#714014: fixed in dhex 0.68-3
has caused the Debian Bug report #714014,
regarding dhex has high CPU usage (30%) due to input processing
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
714014: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714014
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dhex
Version: 0.68-2
Severity: important
Tags: upstream patch

Hello,

I have been looking for a useful console-based hex editor and dhex is a good
candidate, except that it uses a lot of CPU when idling and waiting for the
user's next key press. This happens with an input file of any size
(including
an empty file). The CPU usage ranges from 30% on an i5 to 50% on an AMD
E-350.

I have run dhex through a debugger and looked at the source and the problem
appears to be entirely due to its input processing. The function getkey() in
dhex-0.68/input.c consists of a busy-loop waiting for input, delaying for a
maximum of one microsecond (through usleep(1)).

However, the program still seems to function correctly when asynchronous
input
is disabled. I have tested editing, searching, go to position, etc. This is
assuming ncurses is in cbreak() mode which mine appears to be by default (a
call to cbreak() could also be included). Here is a patch that disables
asynchronous input:

diff --git a/dhex-0.68-orig/main.c b/dhex-0.68/main.c
index e6f014c..21cef37 100644
--- a/dhex-0.68-orig/main.c
+++ b/dhex-0.68/main.c
@@ -525,7 +525,6 @@ int main(int argc,char** argv)
                output->win=initscr();
                pairsinit(output);
                noecho();
-               nodelay(output->win,1);
                if (keyboardsetupreq) keyboardsetup(output,configfile);
                readbuf(buf1,0);
                firstpos1=cursorpos1;

Of course the getkey() input routine could be much simpler if it knows that
getkey() will block, and I recommend that it be rewritten (by someone who
knows
more about ncurses than I). It seems like the routine is trying to handle
multi-character extended keys (arrow keys, function keys) by receiving
blocks
of characters at once and comparing them with a list. This should be
equivalent
to blocking on each getch() call and searching through the list after each
character (which is what my patch will induce, since getch() never returns
ERR
in a blocking context).

If that patch seems too risky, at the very least, the usleep(1) call
(input.c
line 72) could be changed to usleep(1000) to sleep for a millisecond
instead of
a microsecond. This still uses CPU but normally less than 5%. The program
still
functions without apparent latency (the maximum latency introduced would be
1
ms), and it will never miss any input.

diff --git a/dhex-0.68-orig/input.c b/dhex-0.68/input.c
index 34e2e93..8ead185 100644
--- a/dhex-0.68-orig/input.c
+++ b/dhex-0.68/input.c
@@ -69,7 +69,7 @@ tInt16 getkey(tKeyTab* pKeyTab,tBool inputfield)
// =1 this is an inputfield. w
                                lastch=ch;
                                done=1; // a key was pressed
                        } else {
-                               usleep(1);
+                               usleep(1000);
                                donecnt=donecnt-partial;
                                done=!donecnt;
                        }

In this second case, the initial donecnt value should perhaps be
initialized to
a smaller value (for less async getch() calls since there is a bigger delay
between each one). It is curious however that donecnt is never reset to a
nonzero value once it hits zero; is that another bug?

All in all, I recommend that one or the other of my patches be adopted, and
perhaps someone else take a look at the getkey() function. It seems in need
of
review. Cheers.

~ dwk



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dhex depends on:
ii  libc6        2.17-3
ii  libncurses5  5.9+20130608-1
ii  libtinfo5    5.9+20130608-1

dhex recommends no packages.

dhex suggests no packages.

-- no debconf information

--- End Message ---
--- Begin Message ---
Source: dhex
Source-Version: 0.68-3

We believe that the bug you reported is fixed in the latest version of
dhex, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Gürkan Myczko <[email protected]> (supplier of updated dhex package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Wed, 14 Mar 2018 08:27:56 +0100
Source: dhex
Binary: dhex
Architecture: source
Version: 0.68-3
Distribution: unstable
Urgency: medium
Maintainer: Jonathan McCrohan <[email protected]>
Changed-By: Gürkan Myczko <[email protected]>
Description:
 dhex       - ncurses based hex editor with diff mode
Closes: 714014 865731
Changes:
 dhex (0.68-3) unstable; urgency=medium
 .
   * Add myself to Uploaders.
   * Drop stripping, thanks Helmut Grohne. (Closes: #865731)
   * Fix busy waiting for input. (Closes: #714014)
   * Bump debhelper version to 11.
   * Bump standards version to 4.1.3.
Checksums-Sha1:
 488466991cbf9a8c803b8e5a8288d28cdd776e67 1845 dhex_0.68-3.dsc
 0109518726addffea06245e4fcb221427d9c945f 4408 dhex_0.68-3.debian.tar.xz
 046f9a3a7f20b82814f7bbed80488377a051cff2 5395 dhex_0.68-3_source.buildinfo
Checksums-Sha256:
 b6599642ea9e98375aa5b12ff4a790a0cbd4bf1de25edca6082da3823237d511 1845 
dhex_0.68-3.dsc
 874f11cec24ff1c63274a34d1eb86b590b1cca9351982ed6d5aa6b2f085047f4 4408 
dhex_0.68-3.debian.tar.xz
 5a6fedf4e4ce6902b8068442db82d1ea9ca69b5e16338e376c8f32503de27ffe 5395 
dhex_0.68-3_source.buildinfo
Files:
 db37b4b70ee3d8434f54fbea87aadec9 1845 editors optional dhex_0.68-3.dsc
 16f14bb75aa2143fa6da219bc68eee42 4408 editors optional 
dhex_0.68-3.debian.tar.xz
 812406740f2fd3fd418ac8c80a9b8fb1 5395 editors optional 
dhex_0.68-3_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEkjZVexcMh/iCHArDweDZLphvfH4FAlquyZYACgkQweDZLphv
fH4ZHhAA1ICnAO7ZWK+L85FONBVgpT/VdfGt8jbldFXTJmWN6z4ydpANdNhNCEoF
b2namb2rAThRR+uRwHGkP6A+IirOoJEpeyFimLLL4wgn48bQsF9FX6Pjp5e7ob9V
WFs32SVMmoWBuFmmTsN1VSF75rx4csKCug2qZGel9I/I9M5eWc7n4LzjpIQ4IDIQ
1rHzfdZ6PPWe2Ob+Z97QkKwd1jYzzlGbzEXTZj+r9IMsSUdFCnWy9ZS58XXPCn0f
bsbPtaJLRHt1Q9mmB4U/CBaWmygihbbD6i+5tJV3qlhz6ccDDy/GjZLlhpA+AbY7
1uEUkG9lvQyn9CYSEu0+aaBUhLW1+fFzZh342T7aVem6DIF1hRjhKnRKqGHx3BZL
ie0/O9kqSIdDsP3VTwGIjRquhouMXHu4+33R01729GQ3UYVSCv5809ds/HLn61q7
058pNDpOInWxiSIHqmtqn1J3x9ucovIIHLMtrL5fxl8zqnDI8KZQjLsv82T2oouL
0frP65BvyhQY9pTTd3aWTRrvYeoiL7Tf59lLWo93l3OyZrcapBkft1Rx9OyU6JGl
eOsOJ6PTG2eYJtg4fuSKcr8kQkdy4NyutgrnwKM5534v/2797Vpg+lfVaU7yLma9
2W6aW4WZRLxGUGx17hKkC4MR++OeXAl4ynCWlS+dblkUkZxxiRY=
=LuRF
-----END PGP SIGNATURE-----

--- End Message ---

Reply via email to