sway-1.2_1 crashes

[John Kennedy]

On Mon, Oct 07, 2019 at 11:47:30PM +0200, Jan Beich wrote:
> John Kennedy <warlock at phouka.net> writes:
> 
> > I've finally made some progress using wayland (vs X, via sway) and I'm seeing
> > some crashes.  I'm compiling packages myself, so should have the latest.  A
> > sampling of port versions based on what I typically see people ask about:
> >
> > 	sway-1.2_1
> > 	wayland-1.16.0_1
> > 	xwayland-1.19.1_11,1
> > 	xinput-1.6.3
> > 	mesa-dri-18.3.2_7 (should be compiled with llvm80-8.0.1_3)
> > 	mesa-libs-18.3.2_2 (should be compiled with llvm80-8.0.1_3)
> > 	drm-kmod-g20190710 -> drm-fbsd12.0-kmod-4.16.g20190814
> 
> Can you show the version of wlroots package? It's important to rebuild
> sway after every wlroots update. According to semantic versioning when
> major version is 0 (zero) "anything MAY change at any time" i.e., ABI
> may not be backward-compatible even between patch-level releases.

  At the time (~Friday), it was wlroots-0.7.0.  Over the weekend, it looks like
an update got pushed out so now I'm running wlroots-0.8.0 (and sway-1.2_2).
I also made sure (with prejudice) that drm-fbsd12.0-kmod-4.16.g20190814 was
compiled against the running kernel (most of the time the poudriere jail update
seems to force everything to recompile, but just being sure because of KBI).

> >	2019-10-07 09:00:06 - [backend/drm/atomic.c:38] Atomic test failed: Invalid argument
> 
> Probably benign. I also see this on Intel Skylake GT2 with drm-devel-kmod.

  I think my old drm drivers identified mine as a "Intel Haswell (GT2 desktop)".
Motherboard-video on a Dell OptiPlex 9020.

> >	2019-10-07 09:08:18 - [sway/desktop/transaction.c:464] Unable
> > to create transaction timer (some imperfect frames might be rendered):
> > Resource temporarily unavailable
> 
> Does it disappear if you start as "sway -D txn-wait" or "sway -D noatomic"?

  I'll let you know next crash test (see below).

> > When it fails, it drops back to text mode.  It seems to have a combination of
> > "load: 0.16 is not a controlling termal" (load # seems to vary) and what I
> > guess is some binary junk written to stdout.  They keyboard ends up very
> > wedged (can't even gets caps-lock to toggle lights, mouse doesn't move the
> > pointer).  Powering off via button gest a graceful shutdown and the output
> > that I captured, above.
> 
> Try forcing VT switch via timeout or remotely before starting Sway to
> restore console to usable state e.g.,
> 
> # Can be run from direct X11 session (xorg-server)
> $ (sleep 60 && vidcontrol -s 1 </dev/ttyv0) &
> $ (sleep 90 && pkill sway) &
> $ env -u DISPLAY sway -d >/tmp/sway.log 2>&1 &
> 
> Debugging further may require /tmp/sway.log and ~/.sway/config (if exists).

  I do so love things by changing all the constants.

  In any case, this AM, I crunched up the latest 12.1b3 (r353280), upgraded to
this mornings ports (since I saw wlroots bump up), made sure about the DRM
driver and have been doing a stress test of sorts.  In this case, a poudriere
run of my ~520 ports and getting my load average up to 12+.  Up 2.41 hours
so far.  Previous record was more in tens of minutes as I was doing stuff.

  What I typically do (and had it choke) was alt-# into various desktops (~3
is my normal distraction-free eyeball workspace) and run firefox.  So my test
is just xterm, rxvt, xload and xclock.  And this is the the most typing I've
done other than move some windows around and raise-lower their stacking (I
don't know how paranoid to be about input events since some people seem to
have a lot of problems with them).  Very light window creation (I was figuring
out how to wedge in Xresources, and now I have transparency options).

  Basically, divide and conquer some of my behavior.  If it survives, throw in
more stuff.  If it continues to survive, maybe stuff wasn't all compiled just
right (KBI, llvm80 vs 90, etc).  Maybe some weirdness with X & wayland-aware
backends.

  Currently I'm capturing my "sway" output with -d.  My config customization
is minimal (xrdb, alt-vs-windows key, uncommented screen-blank/lock).