Bug#770369: I may have a solution for the bug 770369

[S Andreason]

Arnaud Ceyrolle wrote:
Hello, I think I might have found why Eterm is behaving like this and 
have also a solution.


From the source tarball listed in the page:
https://packages.debian.org/jessie/eterm

at the link in the right :
eterm_0.9.6.orig.tar.gz 



My modification is to just change the line 1564 in src/command.c
from
unsigned short i;
to
unsigned long i;

and recompile, it works for me.

Let me know if it works for you.


Hi Arnaud,

Good job! That fixes the bug.
Eterm is working now.

Stewart

Bug#770369: I may have a solution for the bug 770369

[Arnaud Ceyrolle]

Hello, I think I might have found why Eterm is behaving like this and have
also a solution.

>From the source tarball listed in the page:
https://packages.debian.org/jessie/eterm

at the link in the right :
eterm_0.9.6.orig.tar.gz


My modification is to just change the line 1564 in src/command.c
from
unsigned short i;
to
unsigned long i;

and recompile, it works for me.

The problem was that, a few lines further 1564, eterm tries to close all
the possible file descriptors from 0 up to 65536.
But when using a short integer, there is an overflow, and when i is at the
value 65535
the i++ instruction puts it at 0, so the loop is beginning again for over
65536 iterations and over and over and forever.

That's why you could see its process consuming 100% of the CPU.

Besides that, I'm surprised that the compiler does not warn about comparing
a long int to a short int in a for loop !!

Let me know if it works for you.

regards

-- 
*Arnaud Ceyrolle*