Running a terminal with options

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Got to Options>Preferences>Terminal Program
2. Replace "/usr/bin/xterm" with "/usr/bin/xterm -en ISO8859-15" 
3. Close
4. Open a new file (File>Open>[choose a file to disassemble]>Open

What is the expected output? What do you see instead?

  EDB freezes

What version of the product are you using? On what operating system?

  edb version: 0.9.20

  Linux zbox 3.16.3-gentoo #4 SMP Sat Sep 27 23:04:47 CEST 2014 x86_64 Intel(R) Celeron(R) 2957U @ 1.40GHz GenuineIntel GNU/Linux

Please provide any additional information below.

  QT version is 4.8.5

  I also tried to call a small wrapper script containing my option instead of directly calling xterm, but it freezes too.
  Concerning my use case: what I was looking for, was to use a Latin-9 terminal to debug a program taking Latin-9 input and outputing Latin-9, because my default xterm is UTF-8. There might be a workaround with locales or other environment variables, but I did not manage to find it.

Original issue reported on code.google.com by stephane...@gmail.com on 9 Dec 2014 at 5:48

[GoogleCodeExporter]

Confirmed. Hopefully there is a relatively easy fix :-).

Original comment by evan.teran on 10 Dec 2014 at 2:33

• Changed state: Accepted

[GoogleCodeExporter]

I tried to play around "tty_proc_->start(tty_command, proc_args);" in 
Debugger.cpp but I did not manage to avoid freezes, and since I haven't done 
any C++ en 10 years and I have never done any QT, I decided you had better 
chances to fix it more quickly than I could :-)

Original comment by stephane...@gmail.com on 10 Dec 2014 at 3:23

[GoogleCodeExporter]

Fair enough. It is freezing on the readline, so it may be getting messed up 
with the different locale. I'll try to take a look later in the day.

Original comment by evan.teran on 10 Dec 2014 at 4:59

[GoogleCodeExporter]

Ah, I was not even looking at the right cause, then.

Do not hurry just for me, I was just debugging a toy program.

Original comment by stephane...@gmail.com on 10 Dec 2014 at 7:19

[GoogleCodeExporter]

Not sure if you have had time to investigate already. Reading Qt documentation, 
I can see 2 possible problems with the line:

tty_file_ = file.readLine().trimmed();

1) "QIODevice::readLine" with no parameter does not report errors. Calling 
"trimmed" directly on an erroneous result might no be a good idea, but it 
should not cause a freeze right on this line.

2) "QIODevice::readLine" returns a QByteArray, and so does 
"QByteArray::trimmed", whereas tty_file_ is a QString. There should be a 
conversion.

I think point #2 is more serious than #1.

Original comment by stephane...@gmail.com on 16 Dec 2014 at 10:42

[GoogleCodeExporter]

Thanks for looking into this. Here's some thoughts.

Regarding point #1: I believe that QIODevice::readLine() will return a an empty 
QByteArray() if an error does occur. I am also under the impression that 
trimmed() is well formed on an empty QByteArray() and will just return another 
empty QByteArray(). So I don't think that is really an error here. However, I 
could be wrong, so I'll look into it further.

Point #2 is interesting.

So QString does (by default) have a constructor which accepts a QByteArray and 
will convert it assuming that the contents are an ASCII encoded string. It is 
probably better to make this explicit though since there are configuration 
options which disable this implicit conversion!

Additionally, if the terminal is set to a non-ASCII encoding, this can easily 
go awry (but I would not expect a freeze!).

Finally, I think it would help to clear up what the purpose of this code is.

In order to have edb interact with the terminal, it needs to know which tty it 
is connected to. So when it runs the terminal program, it passes in a tiny 
script which runs the tty command, then attempts to get the terminal's output. 
Which should look something like "/dev/pts/2"

So, as long as the encoding is compatible with ASCII (like UTF-8), the implicit 
conversion should go just fine. But I can see problems with any encoding which 
aren't backwards compatible with ASCII.

I'll have to think on what the best solution is, I'm honestly not sure. I'd 
love to allow arbitrary command line parameters to the terminal, including 
setting the encoding. But, how will edb know which encoding to read the data it 
gets back as?

Thanks again for you efforts. We'll get to the bottom of this!

Original comment by evan.teran on 20 Dec 2014 at 6:47

[GoogleCodeExporter]

I just did some printf (well, qDebug) debugging, and for me, it does not freeze 
in the "readLine", but already on the previous instruction, where it tries to 
open the pipe:

if(file.open(QIODevice::ReadOnly)) {

"temp_pipe" contains a string which looks OK (like 
"/tmp/edb_temp_file_799122953_26342").

I can see the pipe was created in /tmp, but it seems empty (though I am not 
sure whether that point makes sense for a pipe).

Doesn't it freeze there for you ?

This is weird. What can the encoding impact ? I cannot see any character of 
"shell_script" that is not pure ASCII and would mess the execution of the 
script.

Is it possible to check the result of the constructor on this line:
QFile file(temp_pipe);
?

The good point is that all this reminded me why I abandonned C++ :-D

Original comment by stephane...@gmail.com on 20 Dec 2014 at 9:57

[GoogleCodeExporter]

You are right. It is indeed hanging on the open call, not the read. Which is 
interesting because I'm not away of any reason why that should happen :-/

I suppose it's possible that, it's actually a Qt bug. I'm going to play around 
and see what I can come up with.

Thanks for following up.

Original comment by evan.teran on 31 Dec 2014 at 1:46

[GoogleCodeExporter]

So I think this is actually an issue with xterm (unless I am doing something 
wrong here...)

What we've encountered is a combination of two things as far as I can tell:

1. edb will hang if it thinks it ran the terminal, but it didn't write anything 
to the pipe. I'm working to figure out the best way to resolve this.

2. xterm is acting *weird*, it seems that (at least on my system), that I can 
run "xterm -en ISO8859-15" and up pops a window... But, if i try to also pass 
some code to run via the -e option, then it just exits and does nothing!

Can you verify this behavior for me?

I am simply running these on my command line to test

    /usr/bin/xterm -e sh" -c 'echo "hello" ;while :; do sleep 3600; done'"
    # this works and opens a terminal with 'hello' in it

    /usr/bin/xterm -en ISO8859-15 -e sh" -c 'echo "hello" ;while :; do sleep 3600; done'"
    # this does NOT work, just exists with status code 0 ... only difference is the -en flag.

Does the second command for work you?

Another note is that the man page for xterm says the following:

       -en encoding
               This option determines the encoding on which xterm  runs.   It  sets
               the  locale  resource.   Encodings other than UTF-8 are supported by
               using luit.  The -lc option should be used instead of -en  for  sys‐
               tems with locale support.

Honestly, I find this paragraph a little unclear. But it seems that the -en 
flag is at the very least, not recommended.

Anyway, we'll get to the bottom of it. Let me know if that command works for 
you. Thanks.

Original comment by evan.teran on 31 Dec 2014 at 2:55

[GoogleCodeExporter]

Aha! One more data point! The "-hold" flag. This flag prevents the terminal 
from auto-closing when it is done running the shell. So, when I do that I see 
this on the output:

    Couldn't exec: No such file or directory

So, for whatever reason, it can't find "sh" (or one of the other commands, I 
will continue to investigate...)

Original comment by evan.teran on 31 Dec 2014 at 3:01

[GoogleCodeExporter]

I believe I have resolved this as much as I can on my end. You can now set the 
terminal to be "/usr/bin/xterm -en ISO8859-15" and it should work correctly :-).

Also, you have helped me fix a long standing bug where using konsole as the 
terminal didn't work!

Please re-open the bug if the latest SVN does not resolve this for you.

Thanks,
I hope this resolves it for you.

Original comment by evan.teran on 31 Dec 2014 at 3:14

• Changed state: Fixed

[GoogleCodeExporter]

About #11:

I cannot confirm the fix on my setup, for I cannot get a working compiled edb 
at the moment, they all segfault at startup. Something (a library?) must be 
wrong on my system :-( I'll check again later when I can reboot.

About #9:

I experience the same behaviours with the 3 xterm commands as you did.

Original comment by stephane...@gmail.com on 31 Dec 2014 at 2:04

[GoogleCodeExporter]

Interesting, try deleting ~/.config/codef00.com/edb.conf, as it may be trying 
to load plugins from the previous build.

Original comment by evan.teran on 31 Dec 2014 at 3:11

[GoogleCodeExporter]

That solved the segfault, indeed! I would never have thought of that cause, 
thank you.

So, now I can say that the fix seems to run OK (just did a single test, but it 
worked). Thanks again.

On an unrelated note, I noticed that both "make clean" and "make distclean" 
leave all the 18 "lib***.so" files in the main directory. It is probably not a 
real problem, but it doesn't look... clean ;-)

Original comment by stephane...@gmail.com on 31 Dec 2014 at 3:35

[GoogleCodeExporter]

Glad it fixed it! Regarding the not so clean, clean. Unfortunately, this has to 
do with Qt's build system and placing binaries outside of the source directory. 
It just refuses to delete them!

I suppose I can re-investigate this a bit though, since I agree, it's not 
particularly "clean" :-)

Original comment by evan.teran on 31 Dec 2014 at 3:37