Comment 33 for bug 1504626

Oddly enough this indeed is 100% reproducible with nvidia drivers installed. I doubt this has to do with the driver itself but rather with the nvidia GL libs doing fun stuff to memory and/or changing startup speed sufficiently to cause/avoid a timing problem.

This is a grotesquely disheartening bug that I just spent half a day on and I am still not sure it is fixed because of how fiddly this is to test. Also... bloody modset, what is this? the 80's?

Random findings:

a) compile flags matter. while the kubuntu build runs into the config problem, a master build with -DCMAKE_BUILD_TYPE=Debug does not (kubuntu uses -DCMAKE_BUILD_TYPE=None -DCMAKE_BUILD_TYPE=Debian, whatever that means).

b) the toWalletPipe[0] has the same fd number in both modules for some reason, envSocket OTOH does not. this might be nothing. just an observation

c) the failure point is in kwalletd's main.cpp waitForEnvironment; specifically accept() errors out with EINVAL which can be "Socket is not listening for connections, or addrlen is invalid (e.g., is negative).". and indeed addrlen isn't initialized properly...

d) in the pam's start_kwallet failing to create the pipes doesn't cause a return of the function, it supposedly should though. not related to the problem at hand

All that said this seems to fix it, but I have to do some additional testing

diff --git a/src/runtime/kwalletd/main.cpp b/src/runtime/kwalletd/main.cpp
index 39b5ae9..e790afe 100644
--- a/src/runtime/kwalletd/main.cpp
+++ b/src/runtime/kwalletd/main.cpp
@@ -82,8 +82,8 @@ static int waitForEnvironment()
     printf("kwalletd5: waitingForEnvironment on: %d\n", socketfd);

     int s2;
- socklen_t t;
     struct sockaddr_un remote;
+ socklen_t t = sizeof(remote);
     if ((s2 = accept(socketfd, (struct sockaddr *)&remote, &t)) == -1) {
         fprintf(stdout, "kwalletd5: Couldn't accept incoming connection\n");
         return -1;