Activity for Rob Swindell
-
Rob Swindell posted a comment on ticket #135
And the crash (e.g. after failure to connect via SSH): SyncTERM.exe!pthread_mutex_lock(_RTL_CRITICAL_SECTION * mutex) Line 185 C SyncTERM.exe!sftpc_finish(sftp_client_state * state) Line 149 C SyncTERM.exe!ssh_close() Line 1010 C SyncTERM.exe!conn_close() Line 459 C SyncTERM.exe!conn_socket_connect(bbslist * bbs) Line 638 C SyncTERM.exe!ssh_connect(bbslist * bbs) Line 738 C mutex = 0x01366c44 {DebugInfo=0x0139f358 {Type=0x0000 CreatorBackTraceIndex=0x0100 CriticalSection=0x00000000 <null> ...} ...}</null>...
-
Locks up after failing to SSH-authentication with SYSPASS
-
BTW, running msvc build of current git, I see this infinite loop when disconnecting via SSH under these conditions: SyncTERM.exe!sftpc_finish(sftp_client_state * state) Line 167 C SyncTERM.exe!ssh_close() Line 1010 C SyncTERM.exe!conn_close() Line 459 C SyncTERM.exe!doterm(bbslist * bbs) Line 4164 C This is the loop: while (state->running) { pthread_mutex_unlock(&state->mtx); SLEEP(1); pthread_mutex_lock(&state->mtx); }
-
There's other reproducible crashes hanging-up (with Alt-H) during an SSH connection or failing to connect at all (e.g. bad address or hostname), but usually only after one successful SSH connection.
-
Problem is still there with nightly build from March-10. Took 2 tries to make it lock up in the video capture below, but it locked up on the first try the first time (not in the vide).
-
After Alt-H, this is the state of SyncTERM (frozen). The "Connected" counter stops counting and no key presses do anything.
-
Locks up after failing to SSH-authentication with SYSPASS
-
In both cases, it was SDL mode (oops). It (full-screen mouse selection) appears to work fine in GDI mode.
-
No, the selection is starting several cells to the right of where I click, regardless of it's the far left of the displayed text or further in. I was not clicking in the "gutter".
-
Okay, this time with teh mouse pointer captured. Same problem.
-
Mouse selection doesn't work right in full screen mode, Windows
-
If I drag the corner to resize (again, ChromeOS), the window goes black.
-
But if I start syncterm (latest build) on ChromeBook with '-ixf' and then toggle back and forth between windowed and full-screen modes (using Alt-ENTER), no black bars appear! :-)
-
One update, on my Chromebook at today's build, 'syncterm -ixf' works, but not 'syncterm -ix' (gives the black window I attached above).
-
I used to reproduce this my ChromeBook (I think), but a fresh build just gives me a black window now on that same system.
-
Using the current nighlty (02/16/2024 01:23 AM) see video demo
-
Working with the nightly build from 02/16/2024 01:23 AM
-
Copy and paste dialing directory entries
-
Cursor visible in status bar while updating/redrawing
-
When SyncTERM doesn't "run" in this manner, it appears to be leaving an invisible ghost instance running: C:\bin>pslist syncterm Process information for VERT: Name Pid Pri Thd Hnd Mem User Time Kernel Time Elapsed Time syncterm 10644 8 6 283 32300 0:00:00.171 0:00:00.250 0:14:19.612
-
And then SyncTERM locks up (after being disconnected)
-
Eventually, I do get a "You've been inactive too long" message in SyncTERM and disconnected. On the server side log: 2/9 01:31:56p Node 1 <Digital Man> Maximum user input inactivity exceeded 2/9 01:32:02p Node 1 <Digital Man> Digital Man #1 System password attempt: ''
-
SSH connections fail
-
Windows build doesn't run via explorer
-
Option to disable mouse support, per BBS entry
-
Alt-B (View Scrollback) from main menu frequently crashes in Windows (GDI) mode
-
I'm not sure what I was observing at the moment I wrote that either now. I do see the scroll wheel in the SyncTERM scrollback behaves similar to a browser. Never mind. :-)
-
Also, when using the scroll wheel to scroll through the scroll back buffer, the action/result is opposite of my expectations based on browser (on Windows) behavior. In Chrome and Edge on Windows, scrolling down moves the content up. In SyncTERM, scrolling down (in the scrollback) moves the content down.
-
Problem still happens with today's code in git. Run 'syncterm -ixf', then 'syncterm' (configured for non-full-screen) = black bars on sides.
-
Blackbars on sides after transitioning from X11 Fullscreen to X11
-
Sometimes black bars at top and bottom, sometimes not
-
I'm not seeing the black bars or the FPE with today's build. :-)
-
The black bars seems to only happen in 1x scaled output while the FPE appears to happen in either 1x or 2x scaled output.
-
So copying from SyncTERM in X11 mode does work (using 3-finger tap for paste in SyncTERM or in some other ChromeOS or X11 apps, e.g. HexChat yes, but Geany, no). But pasting a selection from say, Chrome, into SyncTERM doesn't work.
-
Possibly related: rswindell@penguin:~/sbbs/src/syncterm$ syncterm Floating point exception (core dumped) ... Thread 3 "X11 Events" received signal SIGFPE, Arithmetic exception. [Switching to Thread 0x7ffff6d55700 (LWP 15349)] 0x000055555572a9db in expose_rect (x=0, y=0, width=1, height=1) at x_events.c:756 756 sx = (x - xoff) / s; (gdb) p x $1 = 0 (gdb) p s $2 = 0 (gdb) p xoff $3 = 0
-
Possibly related: rswindell@penguin:~/sbbs/src/syncterm$ syncterm Floating point exception (core dumped) ... Thread 3 "X11 Events" received signal SIGFPE, Arithmetic exception. [Switching to Thread 0x7ffff6d55700 (LWP 15349)] 0x000055555572a9db in expose_rect (x=0, y=0, width=1, height=1) at x_events.c:756 756 sx = (x - xoff) / s;
-
It's still somewhat "random" (sometimes black on top and bottom, sometimes only on bottom):
-
Square pixel CBM/PETSCII Screen Modes
-
Um... Crostini? https://chromeos.dev/en/linux
-
At least the black bar is only on the bottom now? :-)
-
If I run syncterm i this 1x with black bars mode, then hit Alt-Right to change to 2s scaling and exit, the syncterm.ini is: [SyncTERM] WindowWidth =1280 WindowHeight =800 ScreenMode =LCD80x25 OutputMode =X11 ConfirmClose =true ScalingFactor =2 But I run it again and exit and it gets changed back to 1x ScalingFactor.
-
If I run syncterm i this 1x with black bars mode, then hit Alt-Right to change to 2s scaling and exit, the syncterm.ini is: [SyncTERM] WindowWidth =1280 WindowHeight =800 ScreenMode =LCD80x25 OutputMode =X11 ConfirmClose =true ScalingFactor =2 But I run it again and exit and it gets changed back to 1x ScalingFactor.
-
I rebuilt with the latest (as of right now) and when I ran SyncTERM via shortcut, got 2x scaling, no black bars, but then closed it immediately and ran syncterm again from the command prompt. I then got 1x scaling with black bars. Running a 3rd time from the shortcut and I'm still at 1x with the black bars. Here's the syncterm.ini after doing this: [SyncTERM] WindowWidth =1280 WindowHeight =800 ScreenMode =LCD80x25 OutputMode =X11 ConfirmClose =true ScalingFactor =1
-
I rebuilt with the latest (as of right now) and when I ran SyncTERM via shortcut, got 2x scaling, no black bars, but then closed it and ran syncterm from the command prompt. I then got 1x scaling with black bars:
-
Using an Insert key on a Chromebook is a real challenge: the shortcut key for "insert" is Search + Shift + Backspace. So "shift+insert" doesn't doable.
-
Custom font stopped working
-
On a ChromeBook, there isn't a middle mouse button. I'll plug a 3 button mouse in as a test, but certainly nothing built-in.
-
Setting a dial entry's "Scren Mode" to C64, C128 (40col) or C128 (80col). The font is changed automatically when the screen mode is set in SyncTERM. This is a keyboard input problem, not a display/output problem, from what I can tell. Watching the attached video should make it clear.
-
CTDA response dosen't match cterm.txt
-
ScreenMode isn't saved/updated in syncterm.ini file
-
I see now I was changing the "Current Screen Mode" and not the "Startup Screen Mode". Changing the Program Settings->Startup Screen Mode does in fact get saved/updated in syncterm.ini. My bad.
-
Why is it seemingly random? How does one avoid this behavior?
-
Sometimes black bars at top and bottom, sometimes not
-
Sometimes black bars at top and bottom, sometimes not
-
I confirmed on Debian Linux desktop: cannot copy text from SyncTERM running X11 mode into any other apps (Terminal, Geany, FireFox). Now, pasting into SyncTERM did work however. And whatever I copy to the clipboard in SyncTERM (X11) can be pasted back into SyncTERM, but not any other apps/windows. Running SyncTERM in SDL mode doesn't have this issue.
-
I tried copying from and pasting into Geany (a Linux X11 app), and that works fine. I copy and paste between the ChromeOS Terminal and Geany just fine, but not between either of those and SyncTERM in X11 mode. I'll try with plain ole Debian Linux (not under ChromeOS) as well and let you know how that works.
-
Copy/paste doesn't work in X11 output mode
-
Connecting to any server in Windows console output mode crashes SyncTERM
-
When running full-screen SDL ('syncterm -isf'), the flickering isn't present.
-
Correction: connecting to any servers appears to crash SyncTERM while in Windows console output mode.
-
Connecting to a PETSCII server in Windows output crashes SyncTERM
-
ScreenMode isn't saved/updated in syncterm.ini file
-
PETSCII input characters are case-transposed
-
SyncTERM v1.2b flickers on Windows
-
Thanks for giving it a look-see.
-
Consider iterm2 (graphics) support
-
I can confirm this is still an issue in the latest 1.2b build (for Windows, at least) - file uploads, using any support protocols, do not work.
-
Alt-key res-sizes of the window do remove the black border successfully.
-
This is what the original black border looks like after disconnecting from the non-default-ScreenMode system or re-running SyncTERM after that.
-
Black border around SyncTERM window
-
This project is officially hosted at gitlab.synchro.net.
-
Drag-n-drop upload (via ZMODEM)
-
Remove non-integer scaling (or make it optional)
-
Ymodem-g receive incorrect behavior
-
Fixed: http://cvs.synchro.net/gitpushlog.ssjs#b92bf999e3800568eb4b3e3bbebab87b2443ef51
-
Interestingly, this is how the sexyz/SyncTERM Ymodem-G implementation worked back in 2005 but was inexplicitly changed: http://cvs.synchro.net/cgi-bin/viewcvs.cgi/src/sbbs3/xmodem.c?r1=1.15&r2=1.16
-
Ymodem-g receive incorrect behavior
-
ListFiles
-
ListFiles
-
ListFiles
-
Home
-
Home
-
Home
-
ListFiles
-
List Files
-
Of course ZMODEM can work on a Telnet BBS. The issue (with Telnet) is that character 255 (Telnet IAC) must be doubled on the transmitting side. This behavior is not the default of behavior of DOSBOX. There's a lengthy discussion and patch set here: https://github.com/dosbox-staging/dosbox-staging/pull/582
-
Noticeable keyboard delay when editing text
-
Characters dropped on receive
-
Didn't mean to submit this one anonymously. Oops.
-
Windows XP support
-
Thanks for confirming. The build of cryptlib (the TLS/SSH library) we use does have a patch to address a hard-coded SSH terminal reporting size: https://gitlab.synchro.net/sbbs/sbbs/-/blob/master/3rdp/build/terminal-params.patch And SyncTERM sets the SSH session attributes (CRYPT_SESSINFO_SSH_WIDTH/HEIGHT accordingly): https://gitlab.synchro.net/sbbs/sbbs/-/commit/7aa03d4f47ee2d93879834b64fff21f084f985a4 But it's possible there is a bug. How are you determining the SSH-reported terminal size on the...
-
Can you retry this test with v1.1?
-
Please re-try with v1.1
-
Telnet support enablement for "softmodem" serial ports
-
I originally used X10 mouse mode but switched to "normal" tracking to get scroll wheel events. In any case, if shift-select always copied, then that would work regardless of what mouse tracking mode the BBS had enabled.
-
Here's what the PuTTY docs say about that: "However, it is possible in theory for applications to even detect and make use of Shift + mouse clicks. We don't know of any applications that do this, but in case someone ever writes one, unchecking the ‘Shift overrides application's use of mouse’ checkbox will cause Shift + mouse clicks to go to the server as well (so that mouse-driven copy and paste will be completely disabled). "
-
Shift-mouse-select to copy to clipboard
-
Tilting scroll wheel support
-
Restoring the SyncTERM window after having been minimized, returns to blurry/stretched image
1 >