FP works in PuTTY SSH, FP fails in PuTTY SSH w/TMUX lazarus / 37-Linux PDAs ---------------------------------------------------------------------- ArdRhi · 2018-03-01 19:58 Ok, this is a bit convoluted, but bear with me. I've got FP/Lazarus installed on a Raspi 3 under Raspbian "Stretch". I SSH into it from a Win7 machine, and can flip to HDMI to use the Pi desktop directly if I want, but it's a pain to juggle extra keyboards/mice. I have two SSH windows via PuTTY into the Pi. On one PuTTY window, I run "fp" and the Free Pascal IDE comes up, and works just fine. The other PuTTY window has TMUX running. Even if I only have one pane configured, running "fp" fails with the following message: Runtime Error 106 at $000CA0A4    $000CA0A4    $00010124 I've searched all over and can't find where the point of failure is. It COULD be in my TMUX configuration, and if anyone knows of a more specific place to look, I'd be thankful of the help. I know the setup is silly, and I can forward Lazarus via SSH using Xming and it works fine. But I wanted to see if I could use the old interface, as I first started using Turbo Pascal in the CP/M days, and was nostalgic. ---------------------------------------------------------------------- marcov · 2018-03-02 09:09 FP requires quite a lot from a terminal.  106 is a bit weird error though:  106 Invalid numeric format     Reported when a non-numeric value is read from a text file, and a numeric value was expected. But without debugging the particular situation and build it will be hard. I don't know anybody using tmux with FP. (or tmux at all, which I assume is kind of a screen?) I just tested and FP works with screen in a putty, so it must be some tmux incompatibility. Though I didn't test keybindings. ---------------------------------------------------------------------- mdalacu · 2018-03-02 10:55 I have tested this locally on Ubuntu 17.10 x64 and it fails with same error under tmux. No ssh no nothing, just local terminal session. I have also found an workaround: if you launch screen under tmux...it works oO ---------------------------------------------------------------------- thaolt · 2019-03-13 12:45 Hi, I know it is late but I'm experiencing the same problem currently. I made some diagnostics but I don't know which file to edit in order to correct the issue. First, running fp inside tmux causing the error message: Code: [Select]Runtime error 106 at $00000000004D8C9D                                                                                                              $00000000004D8C9D Then I ran it again with strace and noticed the few last lines: Code: [Select]... open("/proc/26480/stat", O_RDONLY|O_LARGEFILE) = 3 read(3, "26480 (zsh) S 26474 26480 26480 "..., 256) = 256 close(3)                                = 0 open("/proc/26474/stat", O_RDONLY|O_LARGEFILE) = 3 read(3, "26474 (tmux: server) R 1 26474 2"..., 256) = 256 write(2, "Runtime error 106 at $0000000000"..., 39Runtime error 106 at $00000000004D8C9D                                                            ) = 39 write(2, "  $00000000004D8C9D\n", 20  $00000000004D8C9D )   = 20 ioctl(2, TCGETS, {B38400 opost isig icanon echo ...}) = 0 write(2, "\n", 1                                                                                                                                  )                       = 1 munmap(0x7f7c7e0ca000, 32768)           = 0 munmap(0x7f7c7e0c2000, 32768)           = 0 exit_group(106)                         = ? +++ exited with 106 +++ ... Output of the last two accessed stat files: Code: [Select]$ cat /proc/26480/stat 26480 (zsh) S 26474 26480 26480 34818 15692 4194304 8878 118107 1 0 25 13 1368 132 20 0 1 0 4374590 24571904 2074 18446744073709551615 94806579695616 0 $ cat /proc/26474/stat 26474 (tmux: server) S 1 26474 26474 0 -1 4194368 380310 2899732 0 0 614 400 3142 2106 20 0 1 0 4374589 19836928 1045 18446744073709551615 945867047400 I think the problem is fp parses the files with space as delimiter while "(tmux: server)" has space inside it. Recorded screen: https://asciinema.org/a/233446 Please help me find the file need to edit to correct the issue. Thanks, ---------------------------------------------------------------------- marcov · 2019-03-13 13:20 fpc/rtl/linux/linuxvcs.pp   detect_linuxvcs; You can also try to start with "fp -S", though I don't know if that still works (it is a decade ago that I last used that) ---------------------------------------------------------------------- thaolt · 2019-03-13 13:47 Thank you marcov. I have fixed the issue on my machine. "fp -S" still produces the same error code of 106. I think this is not a big issue, here my patch anyway, in case someone may need it. Code: [Select]diff --git a/rtl/linux/linuxvcs.pp b/rtl/linux/linuxvcs.pp index ebae8902..ea4945b4 100644 --- a/rtl/linux/linuxvcs.pp +++ b/rtl/linux/linuxvcs.pp @@ -104,7 +104,8 @@ begin      read(f,c);      repeat        read(f,c); -    until c=' '; +    until c=')'; +    read(f,c);      repeat        read(f,c);      until c=' '; ---------------------------------------------------------------------- Cyrax · 2019-03-13 19:04 Quote from: thaolt on March 13, 2019, 02:47:38 pmThank you marcov. I have fixed the issue on my machine. "fp -S" still produces the same error code of 106. I think this is not a big issue, here my patch anyway, in case someone may need it. Code: [Select]diff --git a/rtl/linux/linuxvcs.pp b/rtl/linux/linuxvcs.pp index ebae8902..ea4945b4 100644 --- a/rtl/linux/linuxvcs.pp +++ b/rtl/linux/linuxvcs.pp @@ -104,7 +104,8 @@ begin      read(f,c);      repeat        read(f,c); -    until c=' '; +    until c=')'; +    read(f,c);      repeat        read(f,c);      until c=' '; Please file a report at the bugtracker and attach your patch in it. Otherwise it will be forgotten.