Bug 187607 - vncserver crashes on FC5 i386
vncserver crashes on FC5 i386
Status: CLOSED DUPLICATE of bug 187069
Product: Fedora
Classification: Fedora
Component: vnc (Show other bugs)
5
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Radek Vokal
David Lawrence
: Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-01 13:01 EST by Esteban Xandri
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-10 10:20:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed patch (1.05 KB, patch)
2006-04-05 09:17 EDT, Jitka Kozana
no flags Details | Diff
vncserver script patch (418 bytes, text/x-patch)
2006-04-05 23:56 EDT, Esteban Xandri
no flags Details
xstartup file in $HOME/.vnc folder (212 bytes, application/octet-stream)
2006-04-25 00:30 EDT, Esteban Xandri
no flags Details
vncserver:1.log file after crashing (619 bytes, text/plain)
2006-04-25 00:31 EDT, Esteban Xandri
no flags Details
patch for null interfaces (395 bytes, patch)
2006-05-02 00:38 EDT, Esteban Xandri
no flags Details | Diff
new vnc.spec file (to include new patch) (19.08 KB, application/octet-stream)
2006-05-02 00:40 EDT, Esteban Xandri
no flags Details

  None (edit)
Description Esteban Xandri 2006-04-01 13:01:41 EST
Description of problem:
vncserver crashes

Version-Release number of selected component (if applicable):
vnc-server-4.1.1-36

How reproducible:
always

Steps to Reproduce:
1.vncserver :1
2.vncerver -kill :1
3.
  
Actual results:
Killing Xvnc process ID 6572
kill 6572: No such process


Expected results:
 a vnc session killed. ps -eaf | grep vnc shows no vnc session running. I have
to remove manually /tmp/.X1-lock and /tmp/.X11-unix/X1 files to retry w/vncserver

Additional info:

no vnc session created. the output of .vnc/servername:1.log is:

xsetroot:  unable to open display ':1'
vncconfig: unable to open display ":1"
xterm Xt error: Can't open display: :1
twm:  unable to open display ":1"
Comment 1 Jitka Kozana 2006-04-05 09:16:49 EDT
Please try it with this patch, and let me know, if it works.  
Thank you.  
 
 
Comment 2 Jitka Kozana 2006-04-05 09:17:29 EDT
Created attachment 127345 [details]
proposed patch
Comment 3 Esteban Xandri 2006-04-05 18:30:36 EDT
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...
Comment 4 Esteban Xandri 2006-04-05 19:24:03 EDT
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...

Comment 5 Esteban Xandri 2006-04-05 21:58:13 EDT
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...
Comment 6 Esteban Xandri 2006-04-05 23:56:47 EDT
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.
Comment 7 Esteban Xandri 2006-04-06 00:03:25 EDT
Last comment: With the packages built using Comment #6 patch, the symnlink of
Comment #4 is no longer necessary.
Comment 8 Jitka Kozana 2006-04-12 06:03:20 EDT
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. 
 
Comment 9 Esteban Xandri 2006-04-25 00:25:06 EDT
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"
Comment 10 Esteban Xandri 2006-04-25 00:30:37 EDT
Created attachment 128176 [details]
xstartup file in $HOME/.vnc folder
Comment 11 Esteban Xandri 2006-04-25 00:31:50 EDT
Created attachment 128177 [details]
vncserver:1.log file after crashing
Comment 12 Esteban Xandri 2006-04-25 00:39:11 EDT
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 ...
Comment 13 Jitka Kozana 2006-04-25 02:16:00 EDT
Thank you. I will look at it. 
Comment 14 Jitka Kozana 2006-04-26 05:16:20 EDT
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.  
  
  
Comment 15 Esteban Xandri 2006-04-26 17:36:33 EDT
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.
Comment 16 Nils Philippsen 2006-04-28 09:15:17 EDT
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.
Comment 17 Nils Philippsen 2006-04-28 09:22:16 EDT
NB: no NVIDIA drivers on that box.
Comment 18 Esteban Xandri 2006-05-02 00:31:26 EDT
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.
Comment 19 Esteban Xandri 2006-05-02 00:38:35 EDT
Created attachment 128464 [details]
patch for null interfaces
Comment 20 Esteban Xandri 2006-05-02 00:40:23 EDT
Created attachment 128465 [details]
new vnc.spec file (to include new patch)
Comment 21 Jitka Kozana 2006-05-10 10:18:54 EDT
This problem should now be fixed in version 4.1.1-38.
Feel free to reopen this bug, if it won't help.
Comment 22 Jitka Kozana 2006-05-10 10:20:44 EDT

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

Note You need to log in before you can comment on or make changes to this bug.