Terminal program for PB622/623

[jtt]

Originally Posted by rkomar

I tried to run the program and got a segfault very early on. Here's what's in the pbterm.log file:

ERROR: posix_openpt() failed: Permission denied

I'm running the 902, with it's latest, but rather old, firmware.

The error message is from the place were the program tries to open the master side of the pseudoterminal and fails. Looks like you have firmware where the '/dev/ptmx' file still has the wrong permissions. And, using the nice trick for splitting the SWUPDATE.BIN files you taught me, I think I can confirm that: the permissions for the file are 644 instead of 666 as the should be. Perhaps I should put in an alternative code path for this case where a set of pipes is used instead.

Are you sure about the segfault? All the program should do when it can't open the PTY is call CloseApp() and die. Well, I'll go through all the destructors to check if there's anything that could be responsible..

Best regards, Jens

[rkomar]

Well, it segfaults if I run it from a utelnetd session or from poterm.app itself. Then I can see what gets printed out. I don't actually know that it crashes in the same place when run from the Application tab. Anyway, here's what I can see when it runs in either of the command-lines above:

bash-4.1$ ./pbterm.app
Atached mp shm: id 0 addr 404ed000 size 17260
Atached mqueue: id 8001
attach_shm: mtfb key=251331154 size=1028432
Atached mtfb shm: id 58006 addr 404f6000 size 1028432
ndepth:2 hqdepth:4
attach_shm: ref key=2130378752 size=993600
Atached ref shm: id 8001 addr 405f2000 size 993600
allocated 500912 bytes for ecmd
Segmentation fault

P.S. I tried to get gdb working on the PB device, but it relies on ncurses to handle the inputs, and that doesn't seem to work inside the utelnetd session unfortunately. Maybe I'll see if gdbserver can get around this somehow.

[rkomar]

I managed to get pbterm.app to run via gdbserver. The segfault occurs in Term::get_shell_output(). I'll need a debugging version of pbterm.app to know more than that.

[jtt]

Originally Posted by rkomar

I managed to get pbterm.app to run via gdbserver. The segfault occurs in Term::get_shell_output(). I'll need a debugging version of pbterm.app to know more than that.

Here it is:

http://users.physik.fu-berlin.de/~jt...1-debug.tar.gz

It contains the application, compiled with "-O0 -g3". Please let me know if you need it compiled in some other way or additional information.

Once I got my WLAN stuff running (but I fear that will have to wait until a new firmware version is out) I'll sk you for help with the reprroducing the setup you've got there (telnet/gdbserver) - that sounds great!

Best regards, Jens

[rkomar]

It's hard to tell with the remote debugging, but it looks like the segfault occurs during the read() because m_pty_fd = -1. I think the function should probably check the file descriptor value first, but in the end, without the pty working properly, nothing correct is ever going to happen anyway, so maybe getting a segfault at that point isn't any worse than just failing gracefully.

[jtt]

Originally Posted by rkomar

It's hard to tell with the remote debugging, but it looks like the segfault occurs during the read() because m_pty_fd = -1. I think the function should probably check the file descriptor value first, but in the end, without the pty working properly, nothing correct is ever going to happen anyway, so maybe getting a segfault at that point isn't any worse than just failing gracefully.

Sounds impossible - read() has no business of segfaulting on a bad file descriptor at all, in that case it's supposed to return -1 and set 'errno' to EBADF - if this can't be relied on then there's a lot more to worry about on this platform than I'd ever have imagined:-(

But then I'm also surprised that you get to the get_shell_output() function if 'm_pty_fd' is negative - that's checked when the PTY is opened and on failure (or other problems) CloseApp() is called. Looks like my assumption that, like exit(), it would terminate the program immmediately, is wrong. I'll put something in that avoids this situation. Thanks for making me aware of this possibility!

Best regards, Jens

PS: The modified version is now available for download.

[rkomar]

I'm not 100% sure that when I call 'step' within gdb in the remote system that it takes just one step. I'm new to remote debugging, so maybe it's not behaving as I expect.

Anyway, the new pbterm-1.3 version still segfaults, so perhaps it is occurring somewhere else than in the read() function call. I'm not sure it's really worth pursuing, since without the pty working, the program will not work anyway. I'll write up some notes on using gdbserver later and put them in a new thread in this PB/Developer section. That way, you and others can try it if you like.

[jtt]

Originally Posted by rkomar

Anyway, the new pbterm-1.3 version still segfaults, so perhaps it is occurring somewhere else than in the read() function call. I'm not sure it's really worth pursuing, since without the pty working, the program will not work anyway.

I'm a bit of a pedant when it comes to programming and I hate segfaults, so I won't stop yet;-) At least I'll try to simulate the situation on my device and check if I can find anything that might be responsible...

I'll write up some notes on using gdbserver later and put them in a new thread in this PB/Developer section. That way, you and others can try it if you like.

That would be very kind of you, thanks a lot!

Best regards, Jens

[jtt]

Hi rkomar,

I just tried to reproduce the SIGSEGV on my machine by setting 'm_pty_fd' to -1 (instead of opening the master side of the PTY), but had no luck in catching any signals as a result, the program seems to exit just normally and as expected. So, at the moment I'm out of ideas what else to try - perhaps the software on your device is too different from that on mine:-(

Best regards, Jens

[jtt]

Hi,

a new version is available (see links in my first post). Beside internal code reorganization the following things have changed in the interface:

a) The program now comes with an (english) keyboard layout file that adds the missing '|' key. Use of the layout is optional and any other can be used (e.g. by setting your favourite layout in the configuration file).

b) A tap on the lower left hand corner of the screen (about a quarter of the screens width and height) brings up the on-screen menu, seems more convenient to me than using a long tap.

c) Also the "Ctrl-D" control character can now be send (to end a program that waits for further input). Use with care since, if send to the shell (instead of to a program started via the shell), the shell itself exits an thus the whole program.

Best regards, Jens

[paolog]

hi jtt
i used version 1.4. with the 4.2 firmware
you must use pbterm.kbd, otherways you can't type more than 4 characters in the command window.
comment or not pbterm.cfg file doesn''t change the behaviour
thanks

[jtt]

Originally Posted by paolog

you must use pbterm.kbd, otherways you can't type more than 4 characters in the command window.

Uups! After I found a potential buffer overrun due to the poor documentation of the libinkview library (and then probably also due to a bug in there, but how can you tell for sure without documentation:-( I made some changes and forgot to remove a 'sizeof' in the branch for "normal" keyboards, sorry. Thank you very much for bringing this to my attention! The new version (1.4.5) just uploaded has this bug fixed.

Best regards, Jens

[jtt]

Hi,

there's a new version that now uses a set of pipes for communication with the shell as a fallback for the case that a pseudoterminal can't be used due to permission issues. In that case the shell can't do job control and sending it control characters is disabled since the shell doesn't recognize them.

Best regards, Jens

[paolog]

Originally Posted by jtt

Uups! After I found a potential buffer overrun due to the poor documentation of the libinkview library (and then probably also due to a bug in there, but how can you tell for sure without documentation:-( I made some changes and forgot to remove a 'sizeof' in the branch for "normal" keyboards, sorry. Thank you very much for bringing this to my attention! The new version (1.4.5) just uploaded has this bug fixed.

Best regards, Jens

hi Jens now works (tried 1.5 version).

The only 'uncomfortable' things is that if I want to use other keyboards I've to move the pbterm.kbd away and then move it back once i did with those layouts.

To comment pbterm.cfg still has no effect

May be you can add the preference to the pop-up dialog with history & ctrl keys?

thanks

Paolo

[jtt]

Hi Paolo,

Originally Posted by paolog

May be you can add the preference to the pop-up dialog with history & ctrl keys?

Your wish is my command;-) Actually, that's a good idea and I have built it into the new version 1.6 you now can download. Thank you for coming up with it!

You can now also disable the use of the custom keyboard completely by putting nothing on the right side of the colon in "keyboard_file" entry in the confguration file.

In an ideal world I would have prefered to be able to switch from the custom keyboard to the default keyboard(s) from within the on-screen keyboard. Unformtunately, the "language button" doesn't seem to work in custom keyboard layouts:-(

Best regards, Jens