Would like info from people who need to set MALLOC_CHECK_

Hi,

I've encountered memory corruption bugs that appear and disappear according to the users setup before. If it's the same problem as what I have observed (and it could easily be so) then it's rather subtle and hard to find. Just in case, let's check shall we?

Some people have reported that they get heap corruption errors from glibc, which look like this:

 *** glibc detected *** double free or corruption (!prev): 0x0af1e410 *** 

Could these people please run SL like this (without the MALLOC_CHECK_ variable set):

LD_DEBUG=files LD_LIBRARY_PATH=lib ./bin/secondlife-bin 2>&1 |grep stdc++

From within the secondlife install directory, if you see libstdc++.so.6 (note the 6 not 5) being loaded then there may be a problem (on my system I can get to the main menu and it's not loaded, but configurations vary a lot ....).

On the other hand, as pointed out elsewhere, SL seems to delete unallocated memory according to valgrind once or twice, so that could be the problem especially if the code run on startup varies a lot according to hardware.

Here's what I get after editing it so "lib" is in the library path too.

tygris@tygris ~/SecondLife $ LD_DEBUG=files LD_LIBRARY_PATH=bin:lib ./bin/secondlife-bin 2>&1 | grep stdc++
25653: file=libstdc++.so.5 [0]; needed by ./bin/secondlife-bin [0]
25653: file=libstdc++.so.5 [0]; generating link map
25653: calling init: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5
*** glibc detected *** double free or corruption (!prev): 0x0af6f328 ***

To compare, it runs fine for me and this is the output when I go to the main menu and quit (in case you're curious):

$ LD_DEBUG=files LD_LIBRARY_PATH=bin:lib ./bin/secondlife-bin 2>&1 | grep stdc++
      8293:     file=libstdc++.so.5 [0];  needed by ./bin/secondlife-bin [0]
      8293:     file=libstdc++.so.5 [0];  generating link map
      8293:     file=libstdc++.so.6 [0];  needed by /usr/lib/libSDL-1.2.so.0 [0]
      8293:     file=libstdc++.so.6 [0];  generating link map
      8293:     calling init: /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/libstdc++.so.6
      8293:     calling init: /usr/lib/libstdc++-v3/libstdc++.so.5
      8293:     calling fini: /usr/lib/libstdc++-v3/libstdc++.so.5 [0]
      8293:     calling fini: /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/libstdc++.so.6 [0]

Yeah, sorry, the LD_LIBRARY_PATH I gave was a typo, it should be lib not bin.

Kitty, can you try again with the fixed LD_LIBRARY_PATH? I'm guessing that unless you fiddled with the install directory v6 will go away then.

LD_DEBUG=files LD_LIBRARY_PATH=lib ./bin/secondlife-bin 2>&1 |grep stdc++
24093: file=libstdc++.so.5 [0]; needed by ./bin/secondlife-bin [0]
24093: file=libstdc++.so.5 [0]; generating link map
24093: calling init: /usr/lib/libstdc++.so.5


Unfortunately, it fails to load.
FC3 - Gnome - Kernel: 2.6.9-1.667 - XOrg 6.8.1 - nVidia FX5200 - 768/1.5 ram

Nope, same thing. It's pulling in v6 because the libSDL I'm using (my system's, not the one supplied with SL) is linked against v6, while the SL binary is linked against v5. As I said, however, SL works for me here, so it doesn't seem to be an issue.

Here's what I get (Fedora Rawhide, haven't posted up my full details in the main thread yet as I'm still working on it):

$ LD_DEBUG=files LD_LIBRARY_PATH=lib ./bin/secondlife-bin 2>&1 |grep stdc++
25964: file=libstdc++.so.5 [0]; needed by ./bin/secondlife-bin [0]
25964: file=libstdc++.so.5 [0]; generating link map
25964: calling init: /usr/lib/libstdc++.so.5
*** glibc detected *** ./bin/secondlife-bin: double free or corruption (!prev): 0x0c47dc18 ***

My system has both /usr/lib/libstdc++.so.5.0.7 (from package compat-libstdc++-33-3.2.3-54.fc5) and /usr/lib/libstdc++.so.6.0.7 (from libstdc++-4.1.0-0.20)

OK, well, scratch that theory then Actually I'm quite happy I am wrong, solving the problem whereby two versions of libstdc++ are linked in at once is a real PITA.

KittyFox, I would *strongly* advise you do not fiddle with the SL configuration like that. What you're doing is dangerous and could lead to hard to debug crashes and problems later on, long after you have forgotten what you did. Is there any particular reason you're using the systems copy of libSDL?

My system is not the fastest thing in the world (a 1GHz with 256MB RAM running KDE). I try to look for ways to squeeze out any more speed as I possibly can. I'm aware that it could cause problems, but a simple 'mv lib.bak~ lib' command and it's back to the provided libs. In fact, I've seen other binary-only games have such tips for speed imporovements (using your system libs in favor of the provided ones).

I really doubt it makes any noticable difference. SDL as used in Second Life is mostly an abstraction and convenience library, and you're unlikely to be running two SDL apps at once so it doesn't matter if it's private. If I were you I'd try and measure the performance difference - if you can't see any, it's not worth it.

The danger with this setup is in future LL may change the code or your setup may change in such a way that it no longer works like this.

Justification for my paranoia is I've seen this sort of problem in Linux games before, it goes something like:

* Game, compiled with GCC 3.2/3.3, which uses libstdc++.so.5, and has STL symbols inlined into it

* Loads private copy of libSDL

* which probes sound drivers, loading libaRts into the process, which is compiled with GCC 3.4/4.0, which uses libstdc++.so.6 and has STL symbols from v6 inlined into it

* The inlines in libaRts despite being defined there are exported as "GLOBAL WEAK" by the compiler, so they get linked like any other symbol back to the v5 copies in the game itself (or the copy of libstdc++.so.5 that was loaded by it)

* aRts uses one of these symbols, typically a std:tring inline (maybe the + op overload), but it's connected to the wrong C++ ABI

* At this point the game usually corrupts its stack or heap, carries on, and crashes at some random later point yards away from the original problem, leading you on a wild goose chase.

This usually gets reported by users as "I ran the game and it crashes" or "I ran the game and it got to the main screen then I click something and it crashes", sometimes with the glibc message, sometimes not. Obviously it only occurs on systems that are compiled with the latest compiler, running a binary copy of the game built with a different compiler (so not from your distro), in which SDL chooses to load libaRts (so, only if you have KDE installed), and only if the phase of the moon means that the game doesn't recover from the stack corruption.

Fortunately it doesn't seem to be what is happening here!