Unable to run new 1.17.0.12 viewer (Signal 7 [SIGBUS] error).

Great, it definitely sounds like it was a libfreetype version skew issue in your case. Has anyone else with the problem tried updating libfreetype? Does it fix the issue after refreshing the linker cache? (Running ldconfig as root should do it, logging out and in again afterward couldn't hurt.)

This was more than likely fixed by updating his C library (libc). The SL viewer is statically linked to libfreetype, so the version on the system makes no difference, unless it's a self-compiled version made to link dynamically.

As an aside, I have tried rolling my own build with my system's version of freetype (2.3.4), as well as various other versions, with no luck. Updating my C library is an impossibility, so I cannot test that theory. None of my local builds (and I've been testing for 3 days now) have worked. This is very frustrating and I am on the verge of stepping back and giving up.

Hi,
just some more comments that confirms what we know by now...
I'm running Debian Sarge (3.1) on a 1.6 GHz P4, 768 MB phys mem and a swapfile that is double the phys if i remember right. Graphics are GeForce 6200.
Everything worked extremely well (besides some network hickups that seemed to rely on a bad netstat due to network hickups) until now.
Bit 1.17-release isn't possible to get going. 3-4 sec of black screen like all of you others out there.
I contacted LL support with the issue to hear if they changed something but all i got was a polite asking to go to... well a warm place, as they only supports the windows-version.
So much for being a paying customer!
Well not all is bad with their support. They have succeeded in giving me access to the forum finally!
I'll give the freetype or c-lib a try if i get the time and they don't break anything else.
And if I get something to work, and still have access to the forum, I'll update you.
For now I am hunting spare parts bringing an old w2k-based computer up to date to be able to get in to SL if it will take time to get the Linux-viewer back on track again...
Talk about a way to go...

[EDIT] I can add that brining libc6 up to a newer version is a huge task, so I can't give it a test right now [/EDIT]

SL is definitely not statically linked to anything. I installed the latest freetype locally, so that with the LD_LIBRARY_PATH the secondlife launcher uses, we pick up the new version. This did not help, so I agree that upgrading libfreetype alone is not the solution.

Not true. If you inspect the libraries that LL includes for building the viewer from source, it includes a libfreetype.a static archive (in linden/libraries/i686-linux/lib_release_client/), which is what it links to when built. The dynamic libfreetype link is a dependency of gtk->pango, which the viewer DOES link to dynamically, but the statically linked library is used by the viewer itself at run-time.

My experience differs on freetype being statically linked:

ldd do-not-directly-run-secondlife-bin
... (much output removed)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb646d000)
...

Compiling it should take care of the difference though. I also built SL the other day, and while it starts up I do get a network error whenever I try to connect. Not sure if you would have had better luck even if there was no freetype error.

Incidentally, updating the C library does take a bit of care when replacing files (I remember how 'exciting' it was updating my old Slackware box while running from a.out to ELF linking format way back when, including libc and libm) but it's possible. Just make sure you have a bootable 'rescue' disc around in case you clobber the C library while updating the way, and remember that static tools are your friend... In any case, you might want to see if a fresh build of LFS works for you if you have an extra PC kicking around.

Hi again,
Just downloaded the SL linux group Live CD (or what ever it was called) from www.libsecondlife.org/sl/
That is based on Knoppix 5.0 and nVidia driver 8xxx (not the latest knoppix, not the latest driver).
I booted that up and guess what, it works just as usual, so it is probably clear that there is some library or something somewhere that messes up the thing under the older systems like Debian.
I guess the only way is to update... *sighs*
Anyone knows what differences to search for between the two systems?

Check the versions of each library that SL is linked with, and the version of GCC that it's built with. Looking at the binary it appears that they're using GCC 3.0, and your C++ libs would need to support the GCC 3.4 CXX (C++) ABI for proper namespace mangling.

Typing 'ldd bin/do-not-directly-run-secondlife-bin' in the second life directory on the system where you're having problems will show you all the libraries the binary is linked with at runtime; note which libraries are older than the ones on the Knoppix CD. A few libs will show up as unresolved, but these are included in the SL distribution and can be ignored. I suppose one way to test would be to copy all the libraries that SL uses from the working Knoppix CD, put them in the 'lib' directory included in the secondlife binary distribution taking care not to overwrite any existing libs, and see if that solves the problem.

The likelihood of it being the C library in only the most recent build seems kind of remote to me. I last updated mine in January, and they would probably have done so around the same time. Previous builds should also have been affected if this were the case. Not knowing their build system update policy though, I suppose anything is possible.

I agree here, though it's a theory I would like to test, but updating glibc on an LFS system is much more painful than on a distribution. I remember my switch from linux-threads to NPTL a few years ago in preparation for moving from a 2.4 kernel to 2.6. Though, I shouldn't have to "fix" my system to resolve a bug *they* introduced. I have been considering doing backups and installing Gentoo... so if a fix isn't found, I suppose I have a bit more incentive to start burning stuff. I may just burn a Live CD and try that out instead. May be able to learn something useful from the system if it works.

As an aside, I am currently rolling a debug build with gcc 4.1.2. It's compiling rather smoothly, only a few small things that I've had to fix so far. GCC4 produces better debug information than GCC3, so I may come up with something useful. Probably wishful thinking, but we shall see.

Do you have enough disk space for a complete chroot copy of your system's OS trees? You could try replacing one lib at a time inside said chroot and see precisely what fixes it.

FWIW, I'm using gcc 4.1.1 myself and everything seemed to compile fine except for mozilla deps and non-OSS items. I disabled them all and the app comes up properly. Unfortunately as I mentioned, the build didn't connect properly to SL so it wasn't terribly useful.

At the moment, not enough space for all of it. Though I wouldn't necessarily need _all_ of it anyway. If all else fails, I can give this a try later, but it would be a lot of work and may end up being fruitless.

I got the web browser stuff to build with gcc4. It's just a few minor bits of bad C++ code that can very easily be fixed (an extra qualifer that can be removed and a missing class declaration). The full thing built and I was able to pull a backtrace in gdb, which I posted on the JIRA issue page for this bug. It provided more information than the gcc3 build, but I am no closer to figuring the issue out. The backtrace indicates it's failing in freetype calls, but I believe this is a side effect of another issue. The freetype case simply doesn't make any sense; all values being passed to it are valid. I suspect stack or memory corruption somewhere. I could just be missing something obvious, as I don't debug C++ code much, usually just C.

Out of curiosity, did you build your client with -ffast-math? It's in the default viewer flags and I've been using it, but I'm doing a build without it right now. I know of many previous cases where -ffast-math can produce bad and/or funky code that does strange things. It could be causing the crash, or it could be masking the real cause. Only one way to find out, I suppose. I doubt the impact on performance will be very big without it anyway...

Disregard. I believe I have found the problem. It isn't the viewer at all. Please see my original post for this thread for more information.

So it's Google's doing then eh? Although it's working fine for me as-is, I echo the sentiment of not linking in tcmalloc. It's probably better to include it in the libs directory but not link it in, since one can always use tcmalloc through an LD_PRELOAD statement before the binary. It would probably make more sense as an option in the secondlife execution script. There are already other options in there that affect stability, why not one more?

Without going too deep and start checking the different librarys that is called (yes the list looks different on the two systems) the main thing that caught the eye is libstdc++ that has numer 6 at the working knoppix setup and numer 5 at the debian sarge system.

I'm still a bit newbie to indeph programming on linux even if I have used it daily since 2003, so pardon the question but how do i do to get a more detailed version numer or something?

Maybe I'll give the compiling as suggested as a solution a try at a later time ad see if that works for me too. But not the next two days.. to much other things that needs attention...

I'll post an update if i find out something more about the issue

SL actually comes with a copy of libstdc++.so.6 in the libs/ directory, which is referenced at runtime by setting the LD_LIBRARY_PATH variable to point to the libs directory (amongst others.) A more detailed version number however would best be obtained from the packaging system, I believe typing 'apt-file search libraryfile.so' should give you the name of the package that it comes from and 'apt-cache show packagename' should give you more information about the file. For the RPM packaging system, you'd use 'rpm -f /system-path/to/library.so' to get the package name, and 'rpm -qi packagename' to get the package info. NVidia's libraries will depend on the version of their driver you have installed, and the same goes for ATI's fglrx libs.

Regardless, I'm pretty sure Alejandro has hit it on the head with the tcmalloc lib. It's intended to be a performance enhancement from what I've read, but if it causes problems on a number of older systems it's less useful. Hopefully LL builds the next release without linking to it, so we can decide whether we want to use it or not at runtime. If not, I suppose someone industrious could write a replacement library which simply wraps the original C library calls.

I know a lot of you are working on it but is it time to get out the Windows XP install disc? I have been without SL on my main computer for a week now. The new viewer still will not run on my Xandros 4.1 system which is based on debian. Has anyone heard from Linden Labs on releasing another version that works? Up to now SL worked perfectly on my HP. I do have a Mac laptop so yes I have been able to get in on my laptop but I want to be able to use my main computer.

Please see: https://jira.secondlife.com/browse/VWR-1184

I have found a fix for it (2 methods for getting it to work, actually). Now that we know the cause, we just have to wait for the Lindens to do something about it. In the mean time, it is possible to make the current client work.

If you are unable to recompile the viewer, there is a second solution (although an ugly one). Execute these commands while in the viewer directory (same directory as './secondlife'):



This replaces the real tcmalloc library with a dummy one which does nothing. The viewer binary does not use any symbols from the library so it is safe to overwrite it. The viewer will then run without crashing from a SIGBUS error.

Good luck.

Thanks for trying to help Alex but using the dirty hack the program still crashes. It may be because I am using an ATI card. Anyway thanks for the help. I think I will set this computer up to dual boot Xandros Linux and Windows XP. At least I will be able to use Windows until this Linux problem is fixed.

Both dirty hack, and rebuild with the patch posted with the ticket worked for me.

AMD Athlon 1.2GHz, 1.5Gb ram, 376Mb swap, Debian Sarge, ATI 9550, fglrx driver 8.19.10...

I have the same problem. Everything ran fine until this new release. What happened?

Thanks Alejandro! I tried running it again. This time I copied and pasted the commands to make sure I did not mistype. It did cause a black void to start eating my desktop. I rebooted my computer and everything was fine. I then opened console and tried to run Second Life again and now IT WORKS PERFECTLY! The viewer loaded, I was able to log into Second Life and the viewer nows works perfectly on my computer.

I may be having a related problem-- but my problem may be related to the R200 open source drivers.

Second Life has long worked for me on lots of systems. The latest release, when I start it on an Athlon with a Radeon 9250, hangs after the line "XML_STATUS_ERROR parsing: if (hour < 5)". There is a black client window open, but nothing gets written into it. Looking at top, Xorg is using up all of my CPU. It just stays that way until I kill the client process.

I've had the same problem on a PIII-1.2GHz laptop with a Radeon Mobility M6. (Pathetic card, but I've been able to run SecondLife at about 3-4fps on this laptop in the past.)

On another machine -- a Pentium-D with a Radeon X800 (using the open source R300 drivers), I have no problem.

All of these machines have the latest drivers out of Debian testing.

I tried the "dirty hack" on the Athlon, but it didn't help. Same problem.

Anybody have any idea what's going on?

-Rob

Hey I was trying to compile a viewer but decided to try the dirty hack. It worked for me! yay! goood enough for now

Thanks for the problem reports. Please see https://jira.secondlife.com/browse/VWR-1184 for an update; we're going to drop tcmalloc for now.