PDA

View Full Version : tss2.rc2-201940 segfaults on Slackware Linux


null
27-01-2004, 22:42
Hello, I am trying to run server_linux on my Slackware box and immediately get a segfault.

Here is the output of uname:
-(../local/teamspeak)#-> uname -srmv
Linux 2.4.19 #2 SMP Sun Mar 16 12:47:19 PST 2003 i686
(Slackware 7.1/glibc-2.2.3)

(I have tried the above and a single cpu Slackware 9.0/glibc-2.3.1 box running 2.4.24 and get the same results.)


Here is the output of ldd:
-(../local/teamspeak)#-> ldd server_linux
/lib/libsafe.so.2 => /lib/libsafe.so.2 (0x40018000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40028000)
libdl.so.2 => /lib/libdl.so.2 (0x4003e000)
libc.so.6 => /lib/libc.so.6 (0x40042000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

-(../local/teamspeak)#-> ldd sqlite.so
/lib/libsafe.so.2 => /lib/libsafe.so.2 (0x4003c000)
libc.so.6 => /lib/libc.so.6 (0x4004c000)
libdl.so.2 => /lib/libdl.so.2 (0x4015d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)


Here is the output of strace:
-(../local/teamspeak)#-> strace ./server_linux
execve("./server_linux", ["./server_linux"], [/* 48 vars */]) = 0
brk(0) = 0x82226c0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0
x40016000
open("/etc/ld.so.preload", O_RDONLY) = 3
fstat64(0x3, 0xbfffeab4) = 0
old_mmap(NULL, 18, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0x40017000
close(3) = 0
open("/lib/libsafe.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\1 6\0\000"..., 1024) =
1024
fstat64(0x3, 0xbfffe61c) = 0
old_mmap(NULL, 17292, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40018000
mprotect(0x4001c000, 908, PROT_NONE) = 0
old_mmap(0x4001c000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x300
0) = 0x4001c000
close(3) = 0
munmap(0x40017000, 18) = 0
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(0x3, 0xbfffe3c4) = 0
old_mmap(NULL, 43983, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001d000
close(3) = 0
open("/lib/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\34 0S\0"..., 1024) = 102
4
fstat64(0x3, 0xbfffe40c) = 0
old_mmap(NULL, 88892, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40028000
mprotect(0x40036000, 31548, PROT_NONE) = 0
old_mmap(0x40036000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xd0
00) = 0x40036000
close(3) = 0
open("/lib/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\36 4\36"..., 1024) = 102
4
fstat64(0x3, 0xbfffe3fc) = 0
old_mmap(NULL, 13296, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4003e000
mprotect(0x40041000, 1008, PROT_NONE) = 0
old_mmap(0x40041000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x200
0) = 0x40041000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\26 4\323"..., 1024) = 10
24
fstat64(0x3, 0xbfffe3ec) = 0
old_mmap(NULL, 1116516, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40042000
mprotect(0x40149000, 39268, PROT_NONE) = 0
old_mmap(0x40149000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x10
6000) = 0x40149000
old_mmap(0x4014f000, 14692, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANON
YMOUS, -1, 0) = 0x4014f000
close(3) = 0
munmap(0x4001d000, 43983) = 0
getpid() = 9985
uname({sys="Linux", node="h4x0r", ...}) = 0
rt_sigaction(SIGRT_0, {0x400313c8, [], 0x4000000}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x40031458, [], 0x4000000}, NULL, 8) = 0
rt_sigaction(SIGRT_2, {0x40031558, [], 0x4000000}, NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [RT_0], NULL, 8) = 0
_sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbfffeca4, 35, (nil), 0}) = 0
getpid() = 9985
readlink("/proc/self/exe", "/usr/local/tss2.rc2-201940/server_linux", 4095) = 39
brk(0) = 0x82226c0
brk(0x82226f0) = 0x82226f0
brk(0x8223000) = 0x8223000
open("/etc/libsafe.exclude", O_RDONLY) = -1 ENOENT (No such file or directory)
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++


I did a search on the posts and came up with one other segfault on the Linux server thread but unfortunately I do not understand German.


Any help on this matter would be greatly appreciated.
~null

null
27-01-2004, 23:31
I just experienced the same with b51.

If you guys need a machine to test on let me know.

~null

null
28-01-2004, 01:59
It appears to be a problem with the libsafe library installed on newer Slackware distributions, I was successful in running the binary on Slackware 7.1/glibc 2.2.3 without that library installed. Perhaps this can be looked into further, if you guys need a machine to test on I can provide you with one.

~null

Dummer Sack
28-01-2004, 13:15
The last error before the segfault is that it could not find the file /etc/libsafe.exclude.
While this may not be the real cuase of the problem you may try to create a legal /etc/libsafe.exclude and see if the error presists.
(I don't know if an empty /etc/libsafe.exclude is legal, but you can try)

null
28-01-2004, 16:30
Thank you for your reply, I was able to get teamspeak running on a older machine without libsafe installed. I did create a libsafe.exclude file and from the man page tried putting the absolute path to teamspeak in that file and rebooted, the binary was still linked against libsafe and continued to segfault. As a test, I commented out /lib/libsafe.so.2 in /etc/ld.so.preload, rebooted and everything was peachy. Perhaps the developers can take a look at this because libsafe is pretty widely used and is an important lib to have installed, either that or perhaps open source the project so development can move a little quicker.

~null

dx9
21-07-2004, 23:21
I have (independently) discovered that TS2 Server RC2 (for linux) DOES have linking issues with (now maintained by Avaya) libsafe.

I tried on several servers then stopped and thought about it, tada, only worked on workstation and none of my servers (which all have libsafe). I came here and discovered the same issue with others. and read about somebody trying the "exclude" option.

After researching here I discovered the libsafe exclude thing:

* Mon Nov 12 2001 Timothy Tsai <ttsai@avaya.com>
- intercept.c:
[...]
- If the current program name is listed in /etc/libsafe.exclude.
This allows libsafe to be linked system-wide (via ld.so.preload),
while disabling libsafe for a small set of incompatible programs.

I just put a oneliner into the /etc/libsafe.exclude that DID NOT include the path
"server_linux"
and made the file world readable (chmod 444)
I will try the full path next (after posting this email). But what I did DOES "workaround" the libsafe issue, with "TS2 Server RC2". Even on my 'Slackware 8.0.0 (åtta)' release (which was JUST before 8.0 went finial). I may have also updated glib and bintools and a few other things, but for the most part, it's pretty much a bare 8.0 machine.

And from what I can tell, server_linux must during run time either load the TWO .so's .. either 'sqlite.so' or 'libsqlmy.so' because 'ldd ./server_linux' does NOT show them. From my personal experience, my gut tells me the problem is HOW 'server_linux' loads one (or both) of those .SO's during run time (like the way apache loads .DSO's). The problem is most likely there!

Just my 2 cents.
BTW> this is the FIRST glib2 program that I've EVER had a conflict with libsafe. I have had issues with mixed libc5 and glib2 systems (even older Slackware 7.x Distro), but that is because libsafe just has issues with older libc5 binaries. (recompile, or upgrade OS)

--Doug

dx9
21-07-2004, 23:27
update

full path to server_linux in the exclude file (for libsafe) also works

tada!

Now... the programmers need to make builds that "work" with libsafe... it has saved a few of my friends from vulerable Apache builds (aka lazy to get around to updating)... It can / might also save TS2 Server RC3 (or later or whatever) from possible exploits YET discovered!!

--Doug