Password Gorilla fails to launch in Fedora 25

[ruoho]

Password Gorilla fails to launch in Fedora 25 under Xwayland (the default now). It will launch under a classic X login.

$ /usr/local/gorilla/gorilla.tcl 
bad pad value "1m": must be positive screen distance
    while executing
"grid [ ttk::label       $pbar.label -text [ format $message 0 ] ] {*}$opts -pady {1m 0}"
    (procedure "::gorilla::progress::init" line 24)
    invoked from within
"::gorilla::progress init -win $aframe.info -message [ mc "Opening ... %d %%" ] -max 200 "
    (procedure "OpenDatabase" line 184)
    invoked from within
"OpenDatabase [mc "Open Password Database"] $defaultFile 1"
    (procedure "gorilla::Open" line 32)
    invoked from within
"gorilla::Open"
    invoked from within
"if {$haveDatabaseToLoad} {
	set action [gorilla::Open $databaseToLoad]
} else {
	set action [gorilla::Open]
}"
    (file "/usr/local/gorilla/gorilla.tcl" line 8780)

[rich123]

It appears you are running the source bundle directly, is that correct?

If so, can you create a tiny tcl file that contains the following two lines:

ttk::label .label -text Testing
grid .label -pady {1m 0}

Then, after saving the file feed it to the wish command like so (assuming the file was named testing.tcl below):

wish testing.tcl

Do you get the same error under Xwayland when launching the test file? If yes, then this is (as I suspect) a bug that exists somewhere between Tcl/Tk and Xwayland. The most Gorilla could do about it is report it upstream to the Tcl/Tk maintainers. And until any fix filtered down from upstream the only workaround would be to launch Gorilla under classic X.

[ruoho]

I'm running from source cloned from the git repo. I get the same error with your test file in Xwayland.

[rich123]

That confirms my suspicion. There's some bug somewhere between Tcl/Tk and Xwayland that ends up manifesting in this visible error. The most I can do is report it upstream to the Tcl/Tk maintainers and wait to learn the outcome.

[rich123]

Is the Tcl/Tk install on Fedora 25 part of the basic distro (i.e., you did not separately install it)? If so you might consider reporting this as a bug in Fedora 25, because it may be an Xwayland bug more-so than a Tcl/Tk bug.

[ruoho]

I used the Tcl/Tk from the distro. I also first tried the larger gorilla Linux binary with the same error, before I switched to source to see if that would resolve the issue.

[rich123]

Then you also have a bug you can report to Fedora. My gut feeling is it is an Xwayland bug where some traditional X API that Xwayland has re-implemented is not acting identically to traditional X. Which means the binary version is of no help, because it is a low level issue So I'd recommend you report a bug to Fedora as well. Supply the test script and point out that it (the test script) works under traditional X but fails under Xwayland.

What is the Tcl/Tk version that Fedora 25 ships with (the Tcl/Tk bug tool rightfully wants to know what version the bug was found in).

[ruoho]

I'll file a bug report with Fedora too.

Fedora 25 is currently at:

$ rpm -qa | egrep ^tcl-\|^tk-
tcl-8.6.6-1.fc25.x86_64
tk-8.6.6-1.fc25.x86_64

[rich123]

Reported to Tcl/Tk maintainers: http://core.tcl.tk/tk/tktview/f5ca2d3be1506b6d066f17da29b15e089a15948b

[rich123]

Another possible workaround you might try is to replace all the Xm pad values with just a numerical value (i.e., if your screen is about 100dpi replacing the 1m above with 4 would give almost the same length). You can search for the "-pad" option string and then modify the argument to the option appropriately.

Before doing this, I'd recommend you try an all numerical value on the two line test script to make sure it seems to work under Xwayland first.

[rich123]

The "m" suffix means millimeter. A plain number is simply pixels. It is possible that a pixel length might work as a workaround for now.

[ruoho]

It looks like the culprit here may really be open-vm-tools. After a window resize, the dimensions are no longer available.

Before resize:

$ xdpyinfo | grep -A1 dimen
  dimensions:    800x600 pixels (212x159 millimeters)
  resolution:    96x96 dots per inch

After resize:

$ xdpyinfo | grep -A1 dimen
  dimensions:    1878x1025 pixels (0x0 millimeters)
  resolution:    -2147483648x-2147483648 dots per inch

[rich123]

I don't know what "open-vm-tools" are, but those values after resize look to be signed integer overflow (or the result of unsigned integer underflow that is then interpreted as if it were signed). Those two huge negative values are the maximum negative integer value for a signed 32-bit 2's compliment integer. And a negative dot-per-inch value will result in nonsense when asking for "millimeters" of distance, resulting in the Tk error you found.

So you have found the culprit, or at least the likely culprit there. I suppose you'd need to report this to the open-vm-tools maintainers.