> If this one is true then this is the problematic code:
> In unix/xc/programs/Xserver/os/auth.c function LoadAuthorization
> ...
> #if !defined(WIN32) && !defined(__UNIXOS2__)
> buf = xalloc (strlen(authorization_file) + 5);
> if (!buf)
> return -1;
> sprintf (buf, "cat %s", authorization_file);
> f = Popen (buf, "r");
> xfree (buf);
> #else
> ...
do you have a clue why it has to be this weird "pipe from cat" way
instead of regular file reading? I just do not see any use case on
'why'?
> This is part of the X server code. I assume that the authorization_file
> is the .xauth file, but I have not checked.
my guess would be ~/.Xauthority ;-)
> There are two possibilities here. Either Popen is buggy, or
> the authorization file string contain crap data. A print statement
> can reveal this.
very very good point... I might have lots of crap there and since noone
seems to experience the same problem on the same box using the same VNC
server and I at the moment have 11 VNC servers running by different
users.
but 'xauth list' looks legit... I just removed now about 10 of obsolete
entries, but I have no other good way to filter automatically filter
from 177 of the others ;-) any of them can be legit -- we have 27 nodes
in the cluster, I might have X session forwarded for a few of them now... I
guess I will clean it out entirely on the next VNC crash whenever I know
for sure that no sessions should be alive.
another point is that my home is NFS-mounted -- ie served to this box
from our file server. although the network seems to be quite stable
eth0 Link encap:Ethernet HWaddr 00:50:45:00:C8:98
RX packets:496933738 errors:0 dropped:0 overruns:0 frame:0
TX packets:781997980 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
eth1 Link encap:Ethernet HWaddr 00:50:45:00:C8:98
RX packets:1300755177 errors:0 dropped:1 overruns:0 frame:0
TX packets:781850420 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
Server rpc stats:
calls badcalls badauth badclnt xdrcall
2031424927 0 0 0 0
who knows...
> However this may not be the true problem as you have reattached here.
> Next time it would be good to know the backtrace. Maybe even check the
> backtrace several times.
yes -- and to don't close running vnc client -- may be it would be helpful
somehow ;-)
> Thanks for all your help. Unfortunatly I do not get this problem myself > so
I need your help to solve this problem. at least 1 happy user of VNC!
;-) just teasing ;-) I am a heavy abuser of VNC, and actually a lucky person to
hit the bugs others do not get.
> Best regards,
Cheers
Yarik
> // Ola
> > --
> > Yaroslav Halchenko
> > Research Assistant, Psychology Department, Rutgers-Newark
> > Student Ph.D. @ CS Dept. NJIT
> > Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
> > 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
> > WWW: http://www.linkedin.com/in/yarik
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
