Bug 187607

Please try it with this patch, and let me know, if it works.  
Thank you.  
 
 

Created attachment 127345 [details]
proposed patch

Had no luck. I patched, rebuilt and reinstalled vnc and vnc-server packages, but
I still see the same symptoms. Going up further, I tried with Xvnc :1 (as user)
instead of vncserver :1, and it ends up in a "Segmentation fault". I guess that
this might be related...

Finally I got vncserver running by installing the vnc-4_1_1-1.i386.rpm from
RealVNC. Although the first attempt failed, the .vnc/servername:1.log showed
that fonts in /usr/X11R6/lib/X11/fonts were not found. I did a chkfontpath -l,
and realized that fonts were moved to /usr/share/X11/fonts in FC5. So then I
tried qith (as root):

cd /usr/X11R6/lib/X11/
ln -s usr/share/X11/fonts

After these steps I recovered my vnc sessions again.
I guess that Fedora's vnc-server package has to be rebuilt to manage the new
fonts path...

After a deeper review to bugzilla, I found that bug 173160 describes the
situation I noticed in Xvnc. According to the changelog, release 4.1.1-20 should
have fixed this font path issue, but it looks like this bug has been resuscitated...

Created attachment 127387 [details]
vncserver script patch

With the attached patch, I was able to rebuild Fedora's packages and run a vnc
session. It changes vncserver script, to include the latest xorg font path as
Xvnc parameters.

Last comment: With the packages built using Comment #6 patch, the symnlink of
Comment #4 is no longer necessary.

I doubt that the main problem that caused vnc to crash was the font issue,   
because for me it works without any problems -- the fontpath   
is /usr/share/X11/fonts and the fonts were found -- even without your patch   
for vncserver. Maybe there was a different problem with your settings.  
   
So if I understand it right, your vnc now works ok?   
 
But I still want to find out, why your vnc was crashing, so if you still are 
able to reproduce it, please send me the log file. Thank you. 
 

Back from my vacations, and after lots of updates I found that my vncserver no
longer works. Not even with the patch of Comment #6. 
Considering that nobody else has reported problems with this package, I agree
with you that the problem is very likely related with my settings, or, as I am
starting to suspect, with the closed source NVIDIA driver I am using (I had to
rebuilt it after the last kernel upgrade to version 2.6.16-1.2096)
One symptom i can reproduce is that using a plain "Xvnc :1" it ends in a
"Segmentation fault"

Created attachment 128176 [details]
xstartup file in $HOME/.vnc folder

Created attachment 128177 [details]
vncserver:1.log file after crashing

Additional information:
I am able to run vncserver using vnc-4_1_1-1.i386.rpm from RealVNC, and, as I
did before, changing the vncserver script to include FC5 fonts paths (fp
parameter of Xvnc).
In case it could be helpful, I included xstartup and (vncserver):1.log files,
but AFAICT, they don't seem to contain any interesting information ...

Thank you. I will look at it. 

Hm. From the files you attached, I cannot tell, what the problem was.   
  
If vpnc (or openvpn) were running, it could cause Xnvnc to segfault (bug 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187069), or the root 
problem could be the caused by the NVIDIA driver, as you suggested.  
  
  

I have no vpnc nor openvp installed/running.
After googling a bit, I found other reports about this problem
(http://www.fedoraforum.org/forum/archive/index.php/t-100274.html).
I uninstalled the Nvidia tarball driver, installed the Livna's rpms driver and
reinstalled all the mesa-libGL* rpms, trying to restore the suggested config
(http://fedoraproject.org/wiki/Xorg/3rdPartyVideoDrivers) but had no luck.
I will keep on searching for more clues.

Tadaa! This bug bit me right now as well, and I don't think it's related to
vpnc/openvpn because running e.g. "Xvnc :4" (after shutting down vpnc and
manually doing "ifconfig tun0 down") crashes on me as well with this
(unqualified, due to no debuginfo installed) backtrace:

(gdb) bt
#0  0x0816e585 in XETrapCloseDown ()
#1  0x0816fb58 in XETrapCloseDown ()
#2  0x08171b5a in EstablishNewConnections ()
#3  0x08079b07 in NotImplemented ()
#4  0x008247e4 in __libc_start_main () from /lib/libc.so.6
#5  0x08057731 in ?? ()

Tell me if I should repeat that with *-debuginfo installed.

NB: no NVIDIA drivers on that box.

After reading Nils report (which describes exactly what was happening to my Xvnc
session) I (again) started to think that this was a bug. So, following his
suggestion, I did install the *-debuginfo rpm. Then I got this output from  
"gdb --args Xvnc :1":

(gdb) run
Starting program: /usr/bin/Xvnc :1
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x795000

Program received signal SIGSEGV, Segmentation fault.
ConvertAddr (saddr=0x0, len=0xbf8a7f00, addr=0xbf8a7efc) at access.c:1861
1861        switch (saddr->sa_family)
(gdb) bt
#0  ConvertAddr (saddr=0x0, len=0xbf8a7f00, addr=0xbf8a7efc) at access.c:1861
#1  0x0816f2d8 in DefineSelf (fd=0) at access.c:983
#2  0x081712ca in CreateWellKnownSockets () at connection.c:432
#3  0x08079ab7 in main (argc=2, argv=0xbf8a8074, envp=0xbf8a8080) at main.c:318
#4  0x007cc7e4 in __libc_start_main () from /lib/libc.so.6
#5  0x08057731 in _start ()
(gdb)

After unsuccessfully trying to find something in
/usr/src/debug/vnc-4_1_1-unixsrc/unix/xorg-server-1.0.1/os/access.c, (surely
because of my lack of C skills...), I decided to do a Google search
(+ConvertAddr+access.c+fault) and ...bingo!: found this link (
http://lists.freedesktop.org/archives/xorg/2006-January/012178.html ), which
describes exactly the situation.
I could test it by shutting down my ppp0 interface and starting Xvnc sessions
without any errors.
As the answer to that email said the bug was solved in CVS, I inspected the last
xorg-x11-server-Xserver ( xorg-x11-server-1.0.1-9.fc5.src.rpm ) and found that
patch xorg-x11-server-1.0.1-SEGV-on-null-interface.patch was meant to solve this
issue.

Long story short, I modified the patch (just to include the new path...) and the
vnc.spec file (obviously to include the new patch), repackage and voilá: I got
vnc sessions again.

Created attachment 128464 [details]
patch for null interfaces

Created attachment 128465 [details]
new vnc.spec file (to include new patch)

This problem should now be fixed in version 4.1.1-38.
Feel free to reopen this bug, if it won't help.

*** This bug has been marked as a duplicate of 187069 ***