xen discuss - Mar 2008 - Solaris Xvnc on SNV64 DomU at Xen 3.2 CentOS 5.1 Dom0 (64 bit)

Install SNV64 DomU at Xen 3.2 CentOS 5.1 Dom0 (64 bit)  without  problems.
Xvnc brought up on SNV 84 DomU per Alan Coopersmith (options 1,2).
Attempt to run at Xen 3.2 CentOS 5.1 Dom0 :-
# vncviewer IP-ADDRESS_DomU:1
provides access only to CDE Desktop. Gnome Desktop crashes.
CDE Desktop works fine.
 
 
This message posted from opensolaris.org

> Install SNV84 DomU at Xen 3.2 CentOS 5.1 Dom0 (64 bit)  without  problems.
> Xvnc brought up on SNV 84 DomU per Alan Coopersmith (options 1,2).
> Attempt to run at Xen 3.2 CentOS 5.1 Dom0 :-
> # vncviewer IP-ADDRESS_DomU:1
> provides access only to CDE Desktop. Gnome Desktop crashes.
> CDE Desktop works fine.
Do you have any idea what exactly crashes when you log into gnome?

Is there any gnome program core dumping?  What happens when 
you enable global core dumps, global setid core dumps and
core dump logging, and then try to log in into gnome ?

    # mkdir /cores
    # coreadm -g /cores/%f-%p
    # coreadm -e global
    # coreadm -e global-setid 
    # coreadm -e log

Are there any core_log messages logged to /var/adm/messages /
dmesg, and core dumps written to directory /cores ?
 
 
This message posted from opensolaris.org

GNOME crashing on SNV84 DomU at Xen 3.2 CentOS 5.1 Dom0
http://bderzhavets.blogspot.com/2008/03/gnome-crashing-on-snv84-domu-at-xen-3.html
 
 
This message posted from opensolaris.org

Is this happened for existing user account ? Can you try to login with 
new user id ?

Boris Derzhavets wrote:
> GNOME crashing on SNV84 DomU at Xen 3.2 CentOS 5.1 Dom0
>
http://bderzhavets.blogspot.com/2008/03/gnome-crashing-on-snv84-domu-at-xen-3.html
>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> xen-discuss mailing list
> xen-discuss@opensolaris.org
>

> GNOME crashing on SNV84 DomU at Xen 3.2 CentOS 5.1 Dom0
>
http://bderzhavets.blogspot.com/2008/03/gnome-crashing-on-snv84-domu-at-xen-3.html
> I was unable to cut and paste this log as text file.
Ok, I think the relevant part of the stack backtrace can be seen in
screendump #2:

#11 <signal handler called>
#12 ... in strcmp() 
#13 ... in get_directory_index()
#14 ... in find_image_offset()
#15 ... in __gtk_icon_cache_get_icon_flags()


It seems that Artem has found the same issue yesterday,
see this thread:

    http://www.opensolaris.org/jive/thread.jspa?messageID=215261


The bug and workaround mentioned in that thread are:

6631419 gtk-update-icon-cache dies on first boot after install/upgrade
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6631419

Workaround:

run the following commands as root:
---8<---
for d in /usr/share/icons/*; do
[ -d $d ] &&
gtk-update-icon-cache --force $d;
done
---8<---
 
 
This message posted from opensolaris.org

Yes, it works.
Thank you very much.
 
 
This message posted from opensolaris.org