<whitequark[cis]>
it looks like if i resize the window, the way the content is scaled changes whenever i open a new X window (like a menu) inside of the wayback session
<whitequark[cis]>
... sorta? that's not quite it ]
<whitequark[cis]>
* ... sorta? that's not quite it
<whitequark[cis]>
okay yeah looks like if i leave the window at its initial 1024x768 size everything works more or less as expected
<whitequark[cis]>
is this an artifact of being unable to communicate output geometry to Xwayland?
<Ariadne>
yeah it scales the root surface
<Ariadne>
changes aren’t yet communicated to xwayland properly
<whitequark[cis]>
thank you, i wasn't sure if it's a bug or not
jvvv has quit [Quit: WeeChat 4.6.3]
jvvv has joined #wayback
scadu has quit [Quit: Idle timeout reached: 172800s]
sq[m] has quit [Quit: Idle timeout reached: 172800s]
dviola has joined #wayback
<f_>
02:10 <whitequark[cis]> unrelated: one more reason to dislike running a matrix homeserver is that my backup grows by about 50 MB/day. that's 18 GB/year!!
<f_>
I heard hackint's matrix homeserver was once at about 150 GB or something
<f_>
Just for an IRC bridge
<whitequark[cis]>
yep
<whitequark[cis]>
i have no idea wtf is synapse doing
<axtlos>
f_: oh yeah i get this too, whenever wayback-compositor dies, xwayland doesn't exit with it, instead it just reparents to the different compositor
<axtlos>
i wonder why that isnt caught by the Xwayback sigchld handler though
<f_>
but here it doesn't actually die, does it?
<f_>
the window stays but it's frozen
<axtlos>
oh hm
<axtlos>
yeah interesting
<axtlos>
you're running a build from HEAD, right?
<f_>
I'm running whatever is packaged in alpine right now
<axtlos>
oh
<axtlos>
i guess try building from the latest commit and see if you can reproduce it?
<f_>
I did not, I copied the binaries to a directory and put that in my PATH
<f_>
though I guess it installs other stuff besides just the binaries?
<axtlos>
yeah thats not enough anymore, either put wayback-compositor in /usr/libexec (or /usr/local/libexec), or set WAYBACK_COMPOSITOR_PATH to the wayback-compositor build
<f_>
that being said I'd argue it shouldn't segfault if not correctly installed so I'll recompile it and troubleshoot
<axtlos>
yes the segfault is defiently not supposed to happen
<axtlos>
well uh my yubikey just died so ill look into the segfault more once i resolve this issue
<f_>
I'm already looking, don't worry :)
<f_>
20229 fun 20 0 20.0T 10640 576 R 79.3 0.1 10:01.06 ./xwayback/Xwayback -d :3
<f_>
what in the workd why is xwayback taking 79% cpu
<f_>
*world
<f_>
and there are like 4 of them
<f_>
woah
<f_>
Probably me.
<axtlos>
oh yeah sometimes xwayback stays as a zombie process when just closing the window
<axtlos>
im not really in a hurry to fix it tbh, i dont think that windowed mode is a big usecase
<f_>
but I believe I found the actual problem to xwayback segfaulting sometimes when not properly installed
<f_>
It really is ../xwayback/xwayback.c:306:3: runtime error: member access within null pointer of type 'struct xway_output'
<axtlos>
oh interesting
<f_>
It's strange that it doesn't happen always, or at least I don't see that segfault much outside of gdb
<f_>
but easy fix
<f_>
hey wayback is on the gitlab.fdo frontpage!
<axtlos>
ohh ok i see why this happens
<axtlos>
we should probably check if wayback-compositor actually launched before continuing
<f_>
Yep
<f_>
I'll fix that, gimme a second
<f_>
what's a bit weird is that doesn't happen outside of gdb
<f_>
race-condition perhaps
<axtlos>
for me its rather confusing why it happens inside gdb
<f_>
I managed to reproduce that issue when running Xwayback multiple times
<axtlos>
assuming you're using a wayland compositor that implements xdg-output, xwayback will just connect to that
<axtlos>
because otherwise it'd quit at xwaybak.c:289, since it cant connect to any wayland compositor
<f_>
sway might implement xdg-output
<axtlos>
yes sway implements it
<axtlos>
either way the fix is easy, just move the wayback_compositor_path definition out of the fork, and check if the set path exists before contiuing
__0x1eaf has quit [Quit: leaving]
<f_>
I was opting more for checking if the compositor is (still) running before proceeding
<f_>
because it's always possible it might be failing to run for some other reason
<f_>
but your solution will allow to print a slightly more user-friendly message I guess
<axtlos>
yeah true, but the issue is how long do you want to keep checking
<axtlos>
oh right also wayback-compositor dying later on is handled by the SIGCHLD handler
<f_>
But the handler doesn't kill Xwayback, does it?
<f_>
ignore what I said, it does
<f_>
or, it should
<axtlos>
yeah it wasnt properly until today because i made it send SIGKILL instead of SIGTERM
<f_>
ookay now I see why it's sometimes not reproducible
<f_>
there's a race-condition in that if Xwayback receives a SIGCHLD before doing much else it'll quit and everything is great
<f_>
but if it gets a SIGCHLD too late it'll be already trying to do weird stuff
<axtlos>
wait the solution may be to just add `signal(SIGSEGV, handle_exit);`
<f_>
hmm bit skeptical about this, a sigsegv should ideally not happen in the first place
<f_>
Anyway I think I'll add some error handling to check if the executable exists in the first place before running it, and I'll also add some checking for xwayback->first_output
<axtlos>
right yeah after the second wl_display_roundtrip there should be a check
<axtlos>
though the SIGSEGV handler should still be added imo, a segfault isnt desirable but if we do get one we should "gracefully" also kill the compositor and xwayland
<f_>
that's true
<axtlos>
maybe make a handle_segv that prints an error and then calls handle_exit
<f_>
yep yep
<axtlos>
f_: ping me once you have the MR open so I can take a look at it
<f_>
thanks :)
<axtlos>
cant do an approval though because of gitlabs weird policy 🥀
<f_>
well IMO you should be a repo "Developer" at least
<f_>
cc Ariadne Son_Goku
<f_>
What I'd like to do while at it is print a more .. userfriendly error on segfault
<f_>
something something "please report this issue to the gitlab repo kthx"
<axtlos>
yeah we definetly need better logging
<axtlos>
at some point also log to /var/log/Xorg.log probably
<f_>
/var/log/Xwayback.log would be better IMO
<f_>
in case there's an Xorg running somewhere you probably don't want to override the logs of that
<axtlos>
well it would be /var/log/Xorg.<display>.log
<axtlos>
thats how Xorg does it iirc
<axtlos>
though we should only start doing that once we have full X compatibility
<f_>
I cannot run the CI though, apparently, so that is currently failing.
<f_>
Apparently only Guest and higher can run CI
<axtlos>
f_: awesome, I'll look at it in a bit
<f_>
ty ^^
arraybolt3 has quit [Quit: Konversation terminated!]
arraybolt3 has joined #wayback
<ConanKudo[m]1>
f_: I've re-run it
pinskia has quit [Read error: Connection reset by peer]
<f_>
ConanKudo[m]1: thank you!
<f_>
axtlos: ok now I think the sleep is actually useless
pinskia has joined #wayback
<f_>
and the issue is located somewhere else entirely
<f_>
but the other commits should kind of solve the common ways I could trigger it
<axtlos>
checking if the compositor is read is already done by wayback.c:286, the solution should be to just unsetenv("WAYLAND_DISPLAY") beforehand so that it doesn't connect to existing compositors
<axtlos>
if i understand the race condition correctly its that xwayback continues before wayback-compositor is up and running
<f_>
and no the MR doesn't fix the "Xwayback stays and uses 100% CPU" issue .... yet
<axtlos>
uhh what exactly is that log you uploaded?
<f_>
me stepping manually through gdb
<f_>
without the error handling
<axtlos>
i mean seems to be working properly then
<axtlos>
thats where its supposed to go
<f_>
So the SIGCHLD handler gets called, but it doesn't exit
<axtlos>
what doesn't exit?
<f_>
Xwayback
<axtlos>
oh
<axtlos>
right yeah
<axtlos>
try doing the unsetenv thing, that should fix it
<f_>
btw regarding the pcmanfm crashing thing, it's not entirely wayback's fault
<f_>
so it seems that that issue with Xwayland deciding to go in sway instead of inside wayback-compositor can be triggered by ... just killing whatever is running in Xwayland when it is in wayback
<f_>
axtlos: aand unsetting WAYLAND_DISPLAY does "fix" the above issue ^
<f_>
but with a side effect
<f_>
could not connect to wayland server
<f_>
(EE)
<f_>
Fatal server error:
<f_>
(EE) Couldn't add screen
<f_>
(EE)
<f_>
This happens when exiting
<axtlos>
when exiting wayback?
<f_>
When killing whatever is running in Xwayland in wayback
<axtlos>
hmm
<f_>
instead of having Xwayland mysteriously run on sway it just prints this
<f_>
but eh, better than nothing
<axtlos>
what about the connect to wayland server part?
<axtlos>
is this with wayback-compositor available?
<f_>
yes
<axtlos>
but everything works fine, right?
<f_>
yes
<axtlos>
ok then this is intended behaviour
<f_>
Only this error when killing whatever DE/WM is running in Xwayland in wayback. Without unsetting WAYLAND_DISPLAY Xwayland would just "escape" wayback
<f_>
so I think that's ok
<axtlos>
Xwayland running in sway is caused by wayback-compositor exiting, Xwayland instead of exiting with it just reparents to the next available wayland display, which in this case is sway
<f_>
yep
<f_>
and by unsetting WAYLAND_DISPLAY it then fails to reparent so it shows this error
<axtlos>
oh wait, the unable to connect to wayland server isnt from us
<axtlos>
then yes this is all good
<f_>
Yes it's not from us
<f_>
it's from Xwayland
<axtlos>
yeah this is a pretty 'crude' error message so i thought its something from wayback lol
<f_>
hehe :p
<f_>
from what I can tell wayback always prefixes messages with either "Xwayback:" or "ERROR:", or with my MR "FATAL:" in the case of a segfault
<f_>
but maybe the entire logging stuff should be made more consistent
<f_>
eh, maybe for another time
<axtlos>
yes we should make logging functions that are shared between all wayback executables
<f_>
axtlos: I updated my MR. Regarding the sigchld handler I'll do some more investigation now
<axtlos>
yep looks good now
<vyivel>
hm what's the problem with sigchld
<f_>
ConanKudo[m]1: What do you mean by "We probably want something similar for Xwayland too?", are you suggesting that I should implement this error handling in Xwayland?
<f_>
or did you mean the compositor
<ConanKudo[m]1>
yeah, and also the env var thing for manually overriding the location of the Xwayland binary
<f_>
I'm not sure what you mean
<f_>
I do check for Xwayland too
<f_>
if there's no Xwayland binary it will complain
<f_>
but the env var thing .. I considered it, thought to myself "maybe for another MR" but I can sneak it in this one if you prefer ^^
<axtlos>
we should do that in another PR, lets not lose the scope too much
<f_>
sure
<axtlos>
f_: also for the sigchld thing, check what pid waitpid() gets, it should be the same as comp_pid but im assuming it isnt, which is why it doesn't trigger properly
<f_>
I put 2 breakpoints, one at line 262 and one at line 273. I `run` until the 1st breakpoint then jump directly to line 272 (the 2nd breakpoint) to not run the error handling stuff that checks if there's a waybackc-ompositor binary
<f_>
then I just step
<f_>
until I enter handle_child_exit
Sario has joined #wayback
__0x1eaf has quit [Read error: Connection reset by peer]
<axtlos>
f_: for some reason xwayland still reparents for me
<axtlos>
actually the real question is why is Xwayland reparenting in the first place
<f_>
hm..
<f_>
axtlos: I have a way cleaner solution wrt reparenting now
<f_>
just telling Xwayland to terminate when it's done
<axtlos>
what do you mean?
__0x1eaf has joined #wayback
<axtlos>
like through an argument?
<f_>
yep, `-terminate`
<axtlos>
hmm
<f_>
I still unset WAYLAND_DISPLAY just in case
<axtlos>
yep that works
<f_>
okay I decided to remove unsetting WAYLAND_DISPLAY after all.
<axtlos>
why?
<f_>
Not sure it does much
<f_>
`-terminate` is enough for Xwayland to properly quit on its own
<axtlos>
right but unsetting WAYLAND_DISPLAY also ensures that Xwayback doesn't connect to the host compositor for xdg-output
<f_>
oh that's true
<f_>
ConanKudo[m]1: if you're still around, can you re-run CI one more time please? And thanks ^^
<f_>
anyway I think I'll call this MR done for now
<f_>
the weird fork issue I'll look at later probably
<axtlos>
oh yeah i wasnt able to reproduce that, i feel like it may be caused by you jumping in gdb
<f_>
yeah probably something on my side
<f_>
for reference I run a fresh alpine linux edge installed yesterday
<f_>
well, postmarketOS specifically, but for my purposes, on this laptop it's pretty much the same thing
<axtlos>
doubt that the distro matters much, I do all my testing on void
<f_>
yeah
<f_>
ConanKudo[m]1: thanks for the CI rerun btw
<jvvv>
when logging is added, maybe should also look at logging the Xwayland process to file as well. afaict Xwayland only logs to stderr, but that could be redirected with dup2 just before the execl
<jvvv>
also, could add -verbose to the Xwayland cmdline
<f_>
yep yep
<axtlos>
-verbose would just be passed if the user specifies it
Chiitoo has quit [Ping timeout: 245 seconds]
<jvvv>
sure
__0x1eaf has quit [Quit: leaving]
<axtlos>
it would be nice if we could have runtime tests in addition to simple build testing
<axtlos>
though that'd probably need something like openqa