Fedora 10, Second Life, crash

Hi,

SecondLife-i686-1.22.1.103637

I had a system using x86_64 Fedora 9 with the latest beta driver from nvidia 180.06. It ran SL just fine.

I've just upgraded to Fedora 10, with the same NVIDIA driver. But now, when I run SL it crashes before the opening screen. See below for the dump of the problem.




2008-11-29T09:28:56Z INFO: getFontListSans: Getting system font list from FontConfig...
2008-11-29T09:28:56Z INFO: getFontListSans: Language en
2008-11-29T09:28:56Z INFO: getFontListSans: Location GB
2008-11-29T09:28:56Z INFO: getFontListSans: Variant UTF-8
2008-11-29T09:28:56Z INFO: getFontListSans: Preferring fonts of language: en
2008-11-29T09:28:56Z INFO: do_elfio_glibc_backtrace: Opening stack trace file /home/sel/.secondlife/logs/stack_trace.log
2008-11-29T09:28:59Z INFO: do_elfio_glibc_backtrace: Finished generating stack trace.
2008-11-29T09:28:59Z INFO: handleViewerCrash: Handle viewer crash entry.
2008-11-29T09:28:59Z INFO: handleViewerCrash: Creating crash marker file /home/sel/.secondlife/logs/SecondLife.error_marker
2008-11-29T09:28:59Z INFO: handleViewerCrash: Created crash marker file /home/sel/.secondlife/logs/SecondLife.error_marker
./secondlife: line 110: 20330 Segmentation fault LD_LIBRARY_PATH="`pwd`"/lib:"`pwd`"/app_settings/mozilla-runtime-linux-i686:"${LD_LIBRARY_PATH}" $LL_WRAPPER bin/do-not-directly-run-secondlife-bin --channel "Second Life Release Candidate" --settings settings_releasecandidate.xml
*** Unclean shutdown. ***

You are running the Second Life Viewer on a x86_64 platform. The
most common problems when launching the Viewer (particularly
'bin/do-not-directly-run-secondlife-bin: not found' and 'error while
loading shared libraries') may be solved by installing your Linux
distribution's 32-bit compatibility packages.
For example, on Ubuntu and other Debian-based Linuxes you might run:
$ sudo apt-get install ia32-libs ia32-libs-gtk ia32-libs-kde ia32-libs-sdl






I've had this message before, and yes... it was fixed when I installed some 32 bit libraries... but in this case, I have no idea which ones or that's even the problem. The stack dump mentioned is below:



0: ELF(do_elfio_glibc_backtrace()+0x109) [0x98e9ef9]
1: ELF(LLAppViewer::handleSyncViewerCrash()+0x13) [0x80e6353]
2: ELF(LLApp:etError()+0x16) [0x9d932f6]
3: ELF(default_unix_signal_handler(int, siginfo*, void*)+0x165) [0x9d93fa5]
4: [0x110410]
5: /lib/libc.so.6(cfree+0x52) [0xc46302]
6: /usr/lib/tls/libnvidia-tls.so.1 [0x465a60]
7: ELF(T1_Face_Done+0x2e0) [0x9af083c]
8: ELF(destroy_face+0x152) [0x9ac7564]
9: ELF(FT_Done_Face+0x81) [0x9ac78ca]
10: /usr/lib/libfontconfig.so.1(FcFreeTypeQuery+0xac) [0x8124dc]
11: /usr/lib/libfontconfig.so.1 [0x80e9dd]
12: /usr/lib/libfontconfig.so.1 [0x80ed1d]
13: /usr/lib/libfontconfig.so.1 [0x80a867]
14: /usr/lib/libfontconfig.so.1(FcConfigBuildFonts+0x4d) [0x80ab1d]
15: /usr/lib/libfontconfig.so.1(FcInitLoadConfigAndFonts+0x1f) [0x812cbf]
16: /usr/lib/libfontconfig.so.1(FcInit+0x2d) [0x812dbd]
17: ELF(LLWindowSDL::getFontListSans()+0x27f) [0x9cd1dbf]
18: ELF(LLWindow::getFontListSans()+0x12) [0x9cc9ed2]
19: ELF(LLAppViewer::initConfiguration()+0x166c) [0x810e43c]
20: ELF(LLAppViewer::init()+0xc0) [0x8111a30]
21: ELF(LLAppViewerLinux::init()+0x11) [0x98e67c1]
22: ELF(main+0x74) [0x98e7b14]
23: /lib/libc.so.6(__libc_start_main+0xe5) [0xbeb6d5]
24: ELF(__gxx_personality_v0@@CXXABI_1.3+0x259) [0x8085dd1]



The crash seems to be occuring when SL tries to get the list of available fonts, but beyond that I am stuck... and I can't get into SL. Can anyone help please?

Thanks

After a bit of investigating using strace... I figured out a workaround. The problem does appear to be in fontconfig. I used strace to see that the segfault was caused when fontconfig catalogued any *.pfa (Adobe type 1) file in usr/share/fonts/default/ghostscript.

The files belong to the rpm:

ghostscript-fonts-5.50-19.fc10.noarch

After moving all of the *.pfa files out of the directory: /usr/share/fonts/default/ghostscript into /var/tmp (storing them out of the way for a test). Second Life works with Fedora 10. Now exactly why it is crashing (seems to be a call to free() that does it)... and if it's a problem in fontconfig or SL.. I don't know. But anyway, as a temp workaround, it seems to be fine.

Fedora 10 wth? was like fedora 2 like yesterday lol.. They sure go through versions like candy


-----------------
VirtualSims.Net - New Free Open World!
(Just Signup and follow the Getting Started Guide on how to connect SL Client Today!)

No faster than *buntu or Mandriva. Many Linux distributions go through a six month development cycle. Linux isn't like Windows, it has a continual, rolling, open system of update and improvement. Bleeding edge distributions like Fedora, Mandriva and *buntu make use of these rapid improvements by continually releasing new versions. For people used to the old fashioned Windows/Mac proprietary way of doing things this seems strange, but it's amazing how you soon get used to new releases and look forward to what is coming up in the next versions!

I think this is one of the reasons why Windows is rapidly getting left behind by Linux!

This may be related to VWR-7386 in JIRA:
http://jira.secondlife.com/browse/VWR-7386

I have boxloads of fonts installed on my 64-bit system, and yum upgrading from F8 to F9 and F9 to F10 I have run into a problem with the fontconfig font cache under /var getting out of sync between the 32-bit cache and the 64-bit cache.

Once they are out of sync, when SL loads and tries to use fontconfig to iterate the available fonts... font-config folds up and takes SL down with it.

I posted one cure in the JIRA for 64-bit Fedora systems.
SL ran for me after that one change.
Maybe that can help with getting your fonts back rather than leaving the in limbo.