[13:17] <alkisg> KitsuWhooa: hi, so, any idea where should we report this? To nouveau upstream? To xorg? To ubuntu?
[13:17] <KitsuWhooa> I'm still working on it
[13:18] <alkisg> Ah great
[13:18] <KitsuWhooa> bisecting goes from one bug to another
[13:18] <alkisg> Btw I haven't heard of any instability issues with pageflip off, from a lot of schools
[13:18] <alkisg> Haha
[13:18] <KitsuWhooa> https://tasossah.com/s/126f55d9cdb3.jpg
[13:19] <alkisg> Are you trying on tnt2 with the segfault, or on the other ones with the corruption?
[13:19] <KitsuWhooa> tnt2
[13:19] <KitsuWhooa> Looking at the code through gdb, the issue is probably somewhere in DIX. It's a bit of a maze
[13:20] <alkisg> Hmm, well, even if you fix the real issue that is the segfault, you wouldn't fix the issue that exposed the segfault, i.e. the lack of initialization somewhere, right?
[13:20] <KitsuWhooa> That is exactly what I am trying not to do
[13:20] <KitsuWhooa> if I wanted to do that, I could add a check for a valid pointer, and if not return
[13:21] <KitsuWhooa> but I doubt that would work
[13:23] <KitsuWhooa> nouveau calls this https://cgit.freedesktop.org/xorg/xserver/tree/exa/exa.c#n66 and this returns an invalid pointer
[13:24] <KitsuWhooa> and ExaPixmapPriv is a macro
[13:24] <KitsuWhooa> which is here
[13:24] <KitsuWhooa> https://cgit.freedesktop.org/xorg/xserver/tree/exa/exa_priv.h#n283
[13:25] <KitsuWhooa> and this in turn calls DIX functions/macros
[13:56] <alkisg> KitsuWhooa: would it be possible to do this? (1) dump vars (2) run xrandr 640x480; xrandr 1366x768; (3) dump vars
[13:56] <alkisg> (1) would be different from (3) in the vars that are not initialized
[13:56] <KitsuWhooa> not really
[13:56] <KitsuWhooa> the function gets called multiple times
[13:57] <alkisg> I'm not talking about the function
[13:57] <alkisg> Suppose xorg somewhere has a variabled named, I dont know, other_page_resolution
[13:57] <alkisg> And this in turn messes things up, and breaks where you see it, but you can't trace it back to the wrong initialization, 
[13:58] <alkisg> so, since xrandr does initialize that internal xorg variable, wouldn't comparing before/after help locate the uninitialized var?
[13:58] <KitsuWhooa> If it's an uninitialized variable, I can probably use valgrind to detect it
[13:58] <KitsuWhooa> dumping every single variable would be very impractical, if not impossible
[13:58] <alkisg> Well since 2 xrandr calls fix it, wouldn't that be the case?
[13:59] <alkisg> I haven't programmed in C/assembly in recent days, but in the old days, I could dump the whole data/stack etc segments and compare
[14:00] <alkisg> And then check the address in the linker to find the variable there...
[14:00]  * alkisg googles about valgrind...
[14:00] <KitsuWhooa> if you go low level like that, possibly
[14:01] <KitsuWhooa> but due to the "refresh rate", you'd probably get a lot of false positives 
[14:03] <alkisg> Wow, just as easy as "valigrind myprogram"? !
[14:04] <KitsuWhooa> yup
[14:04] <alkisg> That sounds too good!
[14:04] <KitsuWhooa> I just switched to one of the cards that have just corruption
[14:04] <KitsuWhooa> so let's see what valgrind says
[14:04] <alkisg> Great
[14:04] <KitsuWhooa> alkisg: does epoptes-client restart whenever a user logs in?
[14:05] <alkisg> There are 2 epoptes-client processes. The system one and the session one. The session one starts on login, so yeah.
[14:05] <KitsuWhooa> Because I found that if I kill the one running already and run it manually from a tty, it doesn't kill the remote sessions
[14:05] <alkisg> You can't kill epoptes (to avoid students doing so),
[14:05] <KitsuWhooa> from a root vt?
[14:05] <alkisg> pkill -QUIT -U "$UID" -f '^epoptes-client$'
[14:05] <alkisg> This sends it a QUIT signal, which it respects
[14:05] <alkisg> Otherwise it restarts
[14:05] <KitsuWhooa> I kill -9 its PID
[14:05] <KitsuWhooa> oops
[14:06] <KitsuWhooa> it doesn't restart for me
[14:06] <alkisg> There's a timeout in the restarting
[14:06] <KitsuWhooa> Ah, I see
[14:06] <alkisg> So you may start it 20 seconds later, and it might be restarted 60 seconds later, killing your "20 seconds later" instance
[14:07]  * alkisg wants to simplify this now with systemd which supports restarting
[14:07] <KitsuWhooa> it doesn't seem to kill it
[14:07] <KitsuWhooa> all I know is that I do that and I can use the shell across X restarts/crashes
[14:08] <alkisg> Make sure UID is defined
[14:08] <alkisg> Eh, you should be able to use the root epoptes-client without restarting it
[14:08] <alkisg> It survives xorg crashes
[14:08] <KitsuWhooa> Once I am done with this I can probably tell you how to reproduce it
[14:09] <KitsuWhooa> and I checked stdout/err and it says nothing when it dies
[14:09] <KitsuWhooa> something complains about socat dying
[14:09] <KitsuWhooa> but I don't think that's the cause
[14:10] <alkisg> Btw if it helps, you can also enable sshd on ltsp clients
[14:10] <alkisg> I never had that issue though, with root epoptes-client dying
[14:10] <KitsuWhooa> it would help, but this ugly workaround seems to be okay so far
[14:10] <KitsuWhooa> so no need yet
[14:12] <KitsuWhooa> would also be nice if there was an easy file transfer option
[14:12] <KitsuWhooa> I just pipe tar to netcat at the moment
[14:12] <KitsuWhooa> to send compiled binaries to clients
[14:14] <KitsuWhooa> that is a lot of uninitalised byte warnings
[14:19] <alkisg> I use python -m SimpleHTTPServer on the server, and wget server:8000/file on the clients, or scp
[14:20] <alkisg> or sshfs
[14:20] <alkisg> There's also LOCAL_APPS_EXTRAMOUNTS=/some/folder in lts.conf, which sshfs's it for you on login
[14:21] <alkisg> Or you can login and /home/username is automounted, and put binaries there on the server, and run them on the client
[14:21] <alkisg> ...the downside being that you need X to login :D
[14:21] <KitsuWhooa> yeeeeah
[14:21] <KitsuWhooa> was about to say that there is nothing in /home/
[14:27] <KitsuWhooa> I don't see anything immediately related in the valgrind output