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

I have found a solution that works for me!

By default, the viewer links against libtcmalloc and libstacktrace. libtcmalloc is used to track memory allocations for catching memory leaks. By simple logic, one can assume this could possibly interfere with regular memory allocations. If you remove (or comment out) the line for adding these to libraries to be linked against in the SContruct file (around line 466), it links and runs as normal.

This works for me and seems to be the cause of the problem. If anyone else experiencing this bug can build their own 1.17.0.12 viewer and use this method and report their results, it would be great.

I recommend that the Lindens disable linking against these libraries (or at the very least, libtcmalloc) unless they're doing a debug build.

Just to exclude all possibilities:

Have you checked your memory? E.g.: http://memtest86.com/

BTW: Is the client immediately crashing or do you get at least to the login screen?

Memory is fine. I do periodic tests with memtest, actually. I've had no problems with the viewer in the past, or any other programs. I tend to leave the viewer running for very long periods of time without any issues, aside from the occasional memory hogging, but with a lot of swap space that doesn't really become an issue.

The window displays, but it's black and only displays for a few seconds before closing. No login screen.

SIGBUS is raised on a bad memory access. Barring a kernel/driver/library issue, it's generally attributable to either a hardware fault or a pointer being sent where it shouldn't go through overly clever pointer arithmetic. Out of curiosity, how much RAM do you have? How much swap have you configured? Do you get the error if you echo "2" into the "/proc/sys/vm/overcommit_memory" file before running SL?

I'm getting the same signal 7 error =(. It creates the window for the login screen for a split second and then crashes. No other errors I could find, just "WARNING: signal_handlers: *** Caught signal 7"

I have a Geforce fx 5500 with the latest available drivers from Nvidia on my Debian install. I have an AMD Athlon xp 1800+ CPU also.

It ran just fine before, now this is happening after the update. Anyone have any suggestions?

Yes, I am aware of what SIGBUS is raised for, which is why I am so confused here. I am very doubtful on a hardware fault, as I have no issues with any other applications. As I stated in the bug report, the 1.16.0.x viewer ran perfectly fine.

My system has 512MB of main memory (504 available to the system), and 381MB of swap space allocated.

Also, no change when setting overcommit_memory to 2.

I've tried multiple kernels, all produce the same result.

This is good to hear. It has me hopeful that it is not a problem specific to my hardware (GeForce4 + Intel CPU) or my system, but it doesn't help us figure out why it's happening. Something changed between 1.16.x and 1.17.x to cause this, but I am unable to determine where the problem is originating from.

Any help on resolving this issue would be greatly appreciated. This is impeding on my ability to work.

I just loaded 1.17.0.12 it up on my system, which has 2GB of RAM, and it seems fine when run normally. When limited to 700MB RAM with "ulimit -v 716800", it dies when it hits the memory limit. I get a signal 6 instead of 7 when it runs out though, so it's probably a different error unless it's due to your swap. Incidentally, do you get a file named 'core' or 'core.xxxxx' where xxxxx is a series of numbers, in the directory where you launch the secondlife executable? You might be able to get a backtrace out of this file with gdb, which would probably be useful for the developer. That would require a bit of work though, since you need to pass the client arguments from within gdb.

Another thing you might want to try is run without swap. If you can't, which I'd understand since it uses more than 500MB on my system around startup, then try creating a swapfile and using that instead of your swap partition as such:

dd if=/dev/zero of=swapfile bs=512 count=780288
mkswap swapfile
swapon swapfile
swapoff /dev/swap-device-partition

You'd need to make sure you had enough free disk space wherever the swapfile went of course, and replace the /dev/swap-device-partition with whatever device is set to swap in your /etc/fstab file.

Good luck!

Actually, the 1.17.0.x viewer provides an automated backtrace upon crashing. This was included in the file I attached to the bug report.



I highly doubt swap is related to this, but I am already using a swap partition + swap file. I've never encountered problems with it previously. The problem here is that the viewer won't even START so it doesn't have a chance to even consume any memory. There are error messages in the system logs from the nVidia drivers, as I mentioned in the bug report. They tend to appear as follows:



This leads me to believe that it is an OpenGL issue or something in the new viewer that disagrees with nVidia's drivers. Thus, this is a bug and not a hardware issue (though it may be directly and specifically related to the official nVidia driver).

Up to Wednesday's new release Second Life ran perfectly on my computer. I have a HP Pentium 4 2.53gz with 2gb of memory and an ATI Radeon 9550 video card. I am running Xandros 4.1 Home Premium edition of Linux which is 32 bit. My computer is also a 32 bit computer. As others have reported the login screen starts to appear but it is black then the program crashes. Yes I also have 1gb of swap space. I also have the latest ATI drivers installed. There is something very wrong with 1.17.0.12.

So, it now appears to not be nVidia specific, nor does memory seem to be a factor. More cases are more evidence that it is a bug in the viewer itself. Yes, something is very wrong.

I'm going to fetch the 1.17.0.12 viewer sources and roll a build (will take a while). With proper debugging symbols in the binary, something should be more easily visible.

We have 512MB of RAM and have been running second life no problem up until the new 1.17.0.12 version. We are also on Linux Xandros oce 3.2.0 using NVidia lastest drivers.

Same problem,

Debian Sarge, GeForce FX 5200, Dual Pentium3 Tualatin (1.2GHz each), 512MRam/512MSwap

Crashes every time, I have no way to log into secondlife now.

I cannot possibly run without swap, SL needs way too much memory for that. I did plan to upgrade memory and swap both this weekend anyway, so I guess I'll find out if that makes a difference.

Is there likely to be a patch release for us or are we basically locked out of the game for the next however many months?

(It's crashing while loading the fonts... ? Am I reading that stacktrace right? Hrmm. )

(I voted for the bug https://jira.secondlife.com/browse/VWR-1184 which does indeed look just like my crash. There are not nearly as many votes as there are people posting here that they have the same thing... )

---
2007-06-15T04:58:12Z INFO: LLViewerImageList::doPreloadImages: Preloading images...
2007-06-15T04:58:13Z INFO: decodeAllImages() took 0.962801 seconds.
2007-06-15T04:58:13Z WARNING: signal_handlers: *** Caught signal 7
2007-06-15T04:58:13Z INFO: remove_marker_file()
2007-06-15T04:58:13Z INFO: do_elfio_glibc_backtrace: Opening stack trace file /home/username/.secondlife/logs/stack_trace.log
2007-06-15T04:58:16Z INFO: do_elfio_glibc_backtrace: Finished generating stack trace.
---
0: ELF(do_elfio_glibc_backtrace()+0x107) [0x96241f7]
1: ELF(viewer_crash_callback()+0x1a4) [0x9633a74]
2: ELF(signal_handlers(int)+0x112) [0x96310a2]
3: [0xffffe420]
4: ELF(tt_face_load_sfnt_header+0x55) [0x9a72000]
5: ELF(sfnt_init_face+0x4b) [0x9a7614c]
6: ELF(cff_face_init+0xad) [0x9a6023d]
7: ELF(open_face+0xdc) [0x9a5545b]
8: ELF(FT_Open_Face+0xfc) [0x9a56fe5]
9: ELF(FT_New_Face+0x3c) [0x9a57370]
10: ELF(LLFont::loadFace(std:tring const&, float, float, float, int, int)+0x3e) [0x96b4a8e]
11: ELF(LLFontGL::loadFace(LLStringBase<char> const&, float, float, float)+0x24) [0x96b8794]
12: ELF(LLFontGL::loadFace(LLFontGL*, LLStringBase<char> const&, float, LLFontList*)+0x8a) [0x96b9bfa]
13: ELF(LLFontGL::initDefaultFonts(float, float, float, LLStringBase<char> const&, float, LLStringBase<char> const&, LLStringBase<char> const&, float, float, float, float, float, LLStringBase<char> const&, float, LLStringBase<char> const&+0x122) [0x96bf212]
14: ELF(LLViewerWindow::initFonts(float)+0x25a) [0x93d845a]
15: ELF(LLViewerWindow::LLViewerWindow(char*, char*, int, int, int, int, int, int)+0x890) [0x93e6c10]
16: ELF(main+0x1c5f) [0x963cadf]
17: /lib/tls/libc.so.6(__libc_start_main+0xf4) [0xb64ff974]
18: ELF(__gxx_personality_v0@@CXXABI_1.3+0x1f5) [0x805c2d1]

Out of curiosity Alejandro, did you get a working build? If a compile makes a difference, I'd guess it might be an ABI-incompatible version skew issue with one or more libraries. If it weren't for Jayce having 2GB of RAM, I'd suspect SL needing to lock a larger chunk of memory in RAM with the newest version... The fact that I'm not having these issues is quite puzzling.

Initial brief window, then crash... don't get anything presented in the window ... solid black.

...
2007-06-15T06:29:41Z INFO: LLViewerImageList::doPreloadImages: Preloading images...
2007-06-15T06:29:42Z INFO: decodeAllImages() took 0.750483 seconds.
2007-06-15T06:29:42Z WARNING: signal_handlers: *** Caught signal 7
...

I have AMD Athlon 1.2GHz, 1.5Gb ram, 376Mb swap, Debian Sarge, ATI 9550, fglrx driver 8.19.10...
No problems (like this) with any prior SL Client.

As indicated above, stacktrace seems to indicate failure while trying to load fonts.

I'm also seeing a change in GPU detection Now I'm seeing this in the console:
...
2007-06-15T06:29:41Z WARNING: loadGPUClass: Couldn't match GPU to a class: Mesa project: www.mesa3d.org Mesa GLX Indirect
2007-06-15T06:29:41Z INFO: initGraphicsFeatureMasks: Setting GPU Class to Class0
2007-06-15T06:29:41Z INFO: maskFeatures: Applying Feature Mask: Class0
2007-06-15T06:29:41Z INFO: maskFeatures: Applying Feature Mask: NoPixelShaders
2007-06-15T06:29:41Z INFO: maskFeatures: Applying Feature Mask: NoVertexShaders
2007-06-15T06:29:41Z INFO: maskFeatures: Applying Feature Mask: OpenGLPre15
...

I was seeing this before, with the 1.16.0.6 Client:
...
2007-06-15T06:06:22Z INFO: loadGPUClass: GPU is ATI Generic
2007-06-15T06:06:22Z INFO: initGraphicsFeatureMasks: Setting GPU Class to Class0
2007-06-15T06:06:22Z INFO: maskFeatures: Applying Feature Mask: Class0
2007-06-15T06:06:22Z INFO: maskFeatures: Applying Feature Mask: ATI
2007-06-15T06:06:22Z INFO: maskFeatures: Applying Feature Mask: OpenGLPre15
...

I'm in the same boat as many of you... no SL until this is fixed...

Yes, most of the people with crashes seem to have no more than 512 MB, except Jayce.

I myself have 1 GB RAM on an Intel Dual Core 2 with nVidia 7600 GS graphics card (driver version: 1.0.8776) and the client runs just fine.

I guess it's not possbile to emulate having 512 MB instead of 1 GB to see what happens with less RAM?

No, I haven't (yet). Even a totally unoptimized, full debug build crashes. The gdb backtrace log indicates bad data being passed to FT_Open_Face from FT_New_Face in libfreetype interally. This may be the trigger, and may indicate a bug in libfreetype itself and not the viewer, but the viewer is somehow triggering it. I am without sleep at the moment so my judgement isn't the greatest.



The @args structure (in which memory_base resides) is locally defined in FT_New_Face and the calling function has no control over what the values of the structure will be, aside from the pathname for the font to load (see src/base/ftobjs.c around line 1062, in libfreetype for this definition).

If this is indeed the cause, I am puzzled as to why the 1.16.x.y viewer did not trigger it, or any prior version for that matter. I will try to make more sense of this after some sleep, or perhaps someone else can figure it out in the mean time (not even sure if I am on the correct path here).

Out of curiosity, does the unicode.ttf symlink in your secondlife directory point to a valid and complete Unicode TTF font when you load SL? I have to make my own unicode.ttf symlink (I use the sazanami-mincho.ttf font instead) whenever I download a new version of SL.

It's possible, you can either boot the kernel with the mem=512M argument or limit a shell to 512MB (for example) with ulimit -v 524288. I tried the latter, but SL died with a signal 6 instead of signal 7 when it ran out of memory.

Yes, I have to relink it as well each time I unpack a new viewer.

It seems that it is still possible to use the FirstLook Windlight viewer version 1.16.0.6.2469! At least it allowed me to go online and enter the world!

Those who are in urgent need to work in SL could give it a try.

SL has been working fine until this update. I have spent a week getting my computer ready to stream and play live in Second Life, finally got my Delta 44 soundcard working and liveice etc. Now with this new update and the stupid fact that using an older version of SL is not an option, I am locked out of Second Life! If they want me to buy a new computer everytime they upgrade , well then SL really is getting too elitist and expensive for me.
Well here is my output. For what it's worth.

007-06-14T21:28:05Z INFO: another_instance_running: Checking marker file for lock...
2007-06-14T21:28:05Z INFO: another_instance_running: Marker file isn't locked.
2007-06-14T21:28:05Z INFO: init_marker_file: Checking marker file for lock...
2007-06-14T21:28:05Z INFO: init_marker_file: Marker file created.
2007-06-14T21:28:05Z INFO: init_marker_file: Removing message.log
2007-06-14T21:28:05Z INFO: Exiting init_marker_file().
2007-06-14T21:28:05Z INFO: write_debug: Opening debug file /home/mercury/.secondlife/logs/debug_info.log
2007-06-14T21:28:05Z INFO: write_system_info: Second Life version 1.17.0
2007-06-14T21:28:05Z INFO: write_system_info: Local time: 2007-06-14T14:28:05 PDT
2007-06-14T21:28:05Z INFO: write_system_info: CPU info:
processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) Processor stepping : 4 cpu MHz : 995.822 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr pni syscall mmxext 3dnowext 3dnow bogomips : 1978.36
2007-06-14T21:28:05Z INFO: write_system_info: Memory info:
MemTotal: 516272 kB MemFree: 32964 kB Buffers: 57136 kB Cached: 273840 kB SwapCached: 8 kB Active: 297708 kB Inactive: 136776 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 516272 kB LowFree: 32964 kB SwapTotal: 522072 kB SwapFree: 520356 kB Dirty: 16 kB Writeback: 0 kB Mapped: 181364 kB Slab: 35732 kB CommitLimit: 780208 kB Committed_AS: 258372 kB PageTables: 1840 kB VmallocTotal: 507896 kB VmallocUsed: 26204 kB VmallocChunk: 481268 kB
2007-06-14T21:28:05Z INFO: write_system_info: OS info: Linux 2.6.11-x1 #1 Mon Apr 25 12:13:32 EDT 2005 i686
2007-06-14T21:28:05Z INFO: main: Loading feature tables.
2007-06-14T21:28:05Z INFO: maskFeatures: Applying Feature Mask: CPUSlow
2007-06-14T21:28:06Z INFO: main: Loading configuration file /home/mercury/.secondlife/user_settings/settings.xml
2007-06-14T21:28:06Z INFO: main: Loading art table from /home/mercury/SecondLife_i686_1_17_0_12/app_settings/viewerart.xml
2007-06-14T21:28:06Z INFO: main: Loading art table from /home/mercury/SecondLife_i686_1_17_0_12/skins/textures/textures.xml
2007-06-14T21:28:06Z INFO: main: Loading base colors from /home/mercury/SecondLife_i686_1_17_0_12/app_settings/colors_base.xml
2007-06-14T21:28:06Z INFO: main: Loading user colors from /home/mercury/SecondLife_i686_1_17_0_12/app_settings/colors.xml
2007-06-14T21:28:06Z INFO: main: Failed to load user colors from /home/mercury/SecondLife_i686_1_17_0_12/app_settings/colors.xml
2007-06-14T21:28:06Z INFO: main: Loading legacy colors from /home/mercury/SecondLife_i686_1_17_0_12/app_settings/colors.ini
2007-06-14T21:28:06Z INFO: initCache: TEXTURE CACHE: Headers: 218103 Textures size: 499 MB
2007-06-14T21:28:06Z INFO: init_cache: VFS CACHE SIZE: 156 MB
2007-06-14T21:28:06Z INFO: init_cache: Renaming /home/mercury/.secondlife/cache/data.db2.x.383244910 to /home/mercury/.secondlife/cache/data.db2.x.86318250
2007-06-14T21:28:06Z INFO: init_cache: Renaming /home/mercury/.secondlife/cache/index.db2.x.383244910 to /home/mercury/.secondlife/cache/index.db2.x.86318250
2007-06-14T21:28:06Z INFO: LLVFS: VFS: Using index file /home/mercury/.secondlife/cache/index.db2.x.86318250 and data file /home/mercury/.secondlife/cache/data.db2.x.86318250
2007-06-14T21:28:06Z INFO: LLVFS: VFS: Using index file /home/mercury/SecondLife_i686_1_17_0_12/app_settings/static_index.db2 and data file /home/mercury/SecondLife_i686_1_17_0_12/app_settings/static_data.db2
2007-06-14T21:28:06Z INFO: main: Initializing window...
2007-06-14T21:28:06Z INFO: ll_try_gtk_init: Starting GTK Initialization.
2007-06-14T21:28:06Z INFO: ll_try_gtk_init: GTK Initialized.
2007-06-14T21:28:06Z INFO: ll_try_gtk_init: - Compiled against GTK version 2.4.14
2007-06-14T21:28:06Z INFO: ll_try_gtk_init: - Running against GTK version 2.6.2
2007-06-14T21:28:06Z INFO: createContext, fullscreen=0 size=1016x709
2007-06-14T21:28:06Z INFO: createContext: Compiled against SDL 1.2.5
2007-06-14T21:28:06Z INFO: createContext: Running against SDL 1.2.11
2007-06-14T21:28:06Z INFO: createContext: creating window 1016x709x32
2007-06-14T21:28:06Z INFO: x11_detect_VRAM_kb: Looking in /var/log/Xorg.0.log for VRAM info...
2007-06-14T21:28:06Z INFO: createContext: X11 log-parser detected 32MB VRAM.
2007-06-14T21:28:06Z INFO: createContext: GL buffer:
2007-06-14T21:28:06Z INFO: createContext: Red Bits 8
2007-06-14T21:28:06Z INFO: createContext: Green Bits 8
2007-06-14T21:28:06Z INFO: createContext: Blue Bits 8
2007-06-14T21:28:06Z INFO: createContext: Alpha Bits 8
2007-06-14T21:28:06Z INFO: createContext: Depth Bits 24
2007-06-14T21:28:06Z INFO: createContext: Stencil Bits 8
2007-06-14T21:28:06Z WARNING: initExtensions: GL extension support forced to SIMPLE level via LL_GL_BASICEXT
2007-06-14T21:28:06Z INFO: initExtensions: Couldn't initialize mipmap generation
2007-06-14T21:28:06Z INFO: initExtensions: Couldn't initialize GL_EXT_paletted_texture
2007-06-14T21:28:06Z INFO: initExtensions: Couldn't initialize anisotropic filtering
2007-06-14T21:28:06Z INFO: initExtensions: Couldn't initialize GL_ARB_occlusion_query
2007-06-14T21:28:06Z INFO: initExtensions: Couldn't initialize GL_ARB_shader_objects
2007-06-14T21:28:06Z INFO: initExtensions: Couldn't initialize GL_ARB_vertex_shader
2007-06-14T21:28:06Z INFO: initExtensions: Couldn't initialize GL_ARB_fragment_shader
2007-06-14T21:28:06Z INFO: initExtensions: GL Probe: Getting symbols
2007-06-14T21:28:06Z INFO: initExtensions: GL Probe: Got symbols
2007-06-14T21:28:06Z INFO: loadGPUClass: GPU is NVIDIA GeForce 2
2007-06-14T21:28:06Z INFO: initGraphicsFeatureMasks: Setting GPU Class to Class0
2007-06-14T21:28:06Z INFO: maskFeatures: Applying Feature Mask: Class0
2007-06-14T21:28:06Z INFO: maskFeatures: Applying Feature Mask: NoPixelShaders
2007-06-14T21:28:06Z INFO: maskFeatures: Applying Feature Mask: NoVertexShaders
2007-06-14T21:28:06Z INFO: maskFeatures: Applying Feature Mask: GeForce2
2007-06-14T21:28:06Z INFO: saveToFile: Saving settings to file: /home/mercury/.secondlife/user_settings/settings.xml
2007-06-14T21:28:06Z INFO: saveToFile: Saving settings to file: /home/mercury/.secondlife/user_settings/settings.xml
2007-06-14T21:28:06Z INFO: LLViewerImageList::doPreloadImages: Preloading images...
2007-06-14T21:28:07Z INFO: decodeAllImages() took 0.714237 seconds.
2007-06-14T21:28:07Z WARNING: signal_handlers: *** Caught signal 7
2007-06-14T21:28:07Z INFO: remove_marker_file()
2007-06-14T21:28:07Z INFO: do_elfio_glibc_backtrace: Opening stack trace file /home/mercury/.secondlife/logs/stack_trace.log
2007-06-14T21:28:13Z INFO: do_elfio_glibc_backtrace: Finished generating stack trace.

Looking at this trace a bit closer, it mentions that the memory is being accessed out of bounds; that is, the program attempted to write data past the memory allocated to the process. It also shows that it's crashing while loading the profintwindows.ttf file, which is the rather small font that comes with SL to begin with. Not really something that should cause an overflow condition. I'm starting to think that perhaps they have built this viewer with a newer build of libfreetype, which would make sense since there was a recent vulnerability in this library.

For those who are having problems with crashing, what is the timestamp on your libfreetype.so.x (libfreetype.so.6.3.10 in my case) library? Was it updated within the last few weeks? You might want to check to see if there's an updated version for your distro. The freetype patch looked innocuous enough, but it can't hurt to check.

I've got libfreetype6 2.1.10-8 installed right now. Looks like etch has version 2.2.1-5. Going to see if upgrading helps. I'll post the results in a few minutes hopefully.

It worked! BTW I originally had 6.3.8, now with 2.2.1-5 it reads 6.3.10.

I'm running Debian(Sarge) and used aptitude to upgrade from the "deb http://ftp.us.debian.org etch main" repository. It made me upgrade the following:
libc6
libc6-dev
initrd-tools
tzdata
locales

And I had to remove base-config, which is for installation setup and can be safely removed.

If you need me to supply any more info let me know.

Thanks! =)