FS#62818 - [xterm] "xtermcontrol --get-geometry" crashes xterm 346-1

Attached to Project: Arch Linux
Opened by Glenn (grepfor) - Wednesday, 05 June 2019, 18:44 GMT
Last edited by Andreas Radke (AndyRTR) - Monday, 01 July 2019, 12:38 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Starting with xterm 346-1, issuing the xtermcontrol(1AUR) command:

$ xtermcontrol --get-geometry

results in immediate 'disappearance' of the xterm window from which it is invoked.

This behaved normally in 345-1 and many predecessors, i.e. returned
the X geometry string. Downgrading from 346-1 to 345-1 is a workaround.


Version info:

xtermcontrol (from AUR): Version 3.6
xterm (repo 'extras'): Version 346-1

Steps to reproduce: See above.
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Monday, 01 July 2019, 12:38 GMT
Reason for closing:  Fixed
Comment by Andreas Radke (AndyRTR) - Wednesday, 05 June 2019, 19:09 GMT
Please report this upstream and maybe bisect the issue.
Comment by Glenn (grepfor) - Wednesday, 05 June 2019, 19:28 GMT
Sure, will do, thanks. (Figured you would say that, I just never know where to file the initial report. I always seem to guess wrong.)
Comment by Thomas Dickey (dickey) - Wednesday, 05 June 2019, 22:06 GMT
It probably depends upon the particular window manager.
xtermcontrol is calling CSI 13 t, which gets the window position.
In #346, I added logic to get the window manager hints, and decode those.
Since that's new code, and I "only" tested a dozen window managers, there's some unexpected behavior :-(
Comment by Glenn (grepfor) - Wednesday, 05 June 2019, 22:11 GMT
It was observed with FVWM, version info below.

Should I report this to fvwm?


"fvwm 2.6.8 compiled on Jan 11 2019 at 08:13:36
with support for: ReadLine, Stroke, XPM, SVG, Shape,
XShm, SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLS"
Comment by Thomas Dickey (dickey) - Wednesday, 05 June 2019, 23:02 GMT
I don't know - I'll try to reproduce it with fwvm.

However, I had mail from someone last fall stating that particular
version of fvwm (on FreeBSD) was causing a crash in xterm due to BadWindow events.
(He wanted to change xterm to ignore errors).

I'll see if I can reproduce it with Arch -
I wasn't able to reproduce it with FreeBSD.
Comment by Thomas Dickey (dickey) - Wednesday, 05 June 2019, 23:22 GMT
hmm - I tried that (compiled xtermcontrol to try that in case it differed from my test-script).
But it's not crashing for me. (I remembered to enable window-ops).
Comment by Thomas Dickey (dickey) - Wednesday, 05 June 2019, 23:24 GMT
Here's a screenshot of xterm after moving the window a couple of times,
running xtermcontrol, as well as running my script (which moves it to
the four corners, getting positions which can be off-screen).
   screenshot.png (626.7 KiB)
Comment by Thomas Dickey (dickey) - Wednesday, 05 June 2019, 23:27 GMT
If it's easy to reproduce in your environment, it might be possible
for you to compile xterm with the debug-trace enabled (which would
tell a lot).

fwiw, my virtual machine's x86_64, so I could provide a binary :-)
Comment by Glenn (grepfor) - Wednesday, 05 June 2019, 23:34 GMT
Hmm. Inch arresting.

I saw it occur in xterms located at several different positions, all sized relatively
typically, 80x30 or 80x40-ish, nothing outlandish or partly off-screen. My fvwm setup is pretty mundane.

Yeah, why don't you shoot me your x86_64 debug-trace binary, I'll try it here.
Comment by Thomas Dickey (dickey) - Wednesday, 05 June 2019, 23:48 GMT
Looking at
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/xterm
I compiled a copy of xterm with the debug-trace enabled (and signed it with my gpg key).
See attached. When running, it will write Trace-parent.out and Trace-child.out with
debugging information to the current directory.

The Trace-parent.out file would be where the get-geometry shows up (near a line with "window_ops").
   arch-62818.tar.xz (346.2 KiB)
Comment by Glenn (grepfor) - Thursday, 06 June 2019, 00:07 GMT
Ok, segfaulted here. I'll send you the trace output via private email,
prefer not to post them here.
Comment by Thomas Dickey (dickey) - Thursday, 06 June 2019, 00:16 GMT
if it dumped core, a traceback (from gdb) might help as well.
Comment by Thomas Dickey (dickey) - Thursday, 06 June 2019, 00:58 GMT
The gdb trace showed me that the problem was in the comparison of the window-manager name,
and I realized that it was not initialized in the case where active-icon is used.
I'll put out a #347 on the weekend with the fix.
Comment by Thomas Dickey (dickey) - Thursday, 06 June 2019, 01:19 GMT
Attaching a simple fix
   arch62818.diff (0.5 KiB)
Comment by Thomas Dickey (dickey) - Saturday, 29 June 2019, 14:55 GMT
fwiw, that's in

https://github.com/ThomasDickey/xterm-snapshots/commit/dab849ea3adfcd9a287269085d99dd03508a6c68#diff-5d3599a5112d2286436726a921ab52b3

shortly after this report, there were others, including

https://trac.macports.org/ticket/58313

which probably will conclude #347
Comment by Thomas Dickey (dickey) - Sunday, 30 June 2019, 23:41 GMT
I'm done with #347 (which should fix this bug).

Loading...