View Full Version : Segmentation Fault
HI,
Mein Teamspeak II Server will einfach nicht mehr starten bzw. beendet er sich gnadenlos mit einem deftigen Segmentation fault:
/etc/rc.d/init.d/teamspeak2: line 31: 6281 Segmentation fault ./server_linux -PID=tsserver2.pid
auch ein direktes starten im tss2 Verzeichnis bringt keine nennenswerten Fortschritte:
[root@ns2 tss2]# ./server_linux
Segmentation fault
[root@ns2 tss2]#
Das installierte System ist ein Up2Date RedHat 7.2 EN FULL System.
Derzeitiges Kernel:
[root@ns2 tss2]# uname -a
Linux ns2.polynaturedesign.com 2.4.9-34enterprise #1 SMP Sat Jun 1 06:05:54 EDT 2002 i686 unknown
und hier nun ein paar infos fuer die Entwickler:
LDD
[root@ns2 tss2]# ldd ./server_linux
/lib/libsafe.so.2 => /lib/libsafe.so.2 (0x40019000)
/lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x4001e000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4003b000)
libdl.so.2 => /lib/libdl.so.2 (0x40050000)
libc.so.6 => /lib/i686/libc.so.6 (0x40054000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
STRACE
[root@ns2 tss2]# strace ./server_linux
execve("./server_linux", ["./server_linux"], [/* 32 vars */]) = 0
uname({sys="Linux", node="ns2.polynaturedesign.com", ...}) = 0
brk(0) = 0x81cb22c
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
open("/etc/ld.so.preload", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=18, ...}) = 0
old_mmap(NULL, 18, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0x40018000
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\20 \17\0"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=21303, ...}) = 0
old_mmap(NULL, 19032, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40019000
mprotect(0x4001d000, 2648, PROT_NONE) = 0
old_mmap(0x4001d000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x3000) = 0x4001d000
close(3) = 0
munmap(0x40018000, 18) = 0
open("/lib/libNoVersion.so.1", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0755, st_size=15849, ...}) = 0
close(3) = 0
open("/lib/libNoVersion.so.1", 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\0000 \10\0"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=15849, ...}) = 0
old_mmap(NULL, 7168, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001e000
mprotect(0x4001f000, 3072, PROT_NONE) = 0
old_mmap(0x4001f000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x4001f000
close(3) = 0
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=108904, ...}) = 0
old_mmap(NULL, 108904, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40020000
close(3) = 0
open("/lib/i686/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\0pP\ 0\000"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=531552, ...}) = 0
old_mmap(NULL, 85040, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4003b000
mprotect(0x40048000, 31792, PROT_NONE) = 0
old_mmap(0x40048000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xc000) = 0x40048000
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\0P\3 6\0\000"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=66069, ...}) = 0
old_mmap(NULL, 12756, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40050000
mprotect(0x40053000, 468, PROT_NONE) = 0
old_mmap(0x40053000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2000) = 0x40053000
close(3) = 0
open("/lib/i686/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\0p\3 07\1"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=5792553, ...}) = 0
old_mmap(NULL, 1293384, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40054000
mprotect(0x40187000, 35912, PROT_NONE) = 0
old_mmap(0x40187000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x132000) = 0x40187000
old_mmap(0x4018c000, 15432, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4018c000
close(3) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000
munmap(0x40020000, 108904) = 0
modify_ldt(0x1, 0xbfffe66c, 0x10) = 0
getpid() = 6502
rt_sigaction(SIGRT_0, {0x400444b0, [], 0x4000000}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x40043890, [], 0x4000000}, NULL, 8) = 0
rt_sigaction(SIGRT_2, {0x40044500, [], 0x4000000}, NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [32], NULL, 8) = 0
_sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbfffe31c, 34, (nil), 0}) = 0
readlink("/proc/self/exe", "/etc/tss2/server_linux", 4094) = 22
brk(0) = 0x81cb22c
brk(0x81cb25c) = 0x81cb25c
brk(0x81cc000) = 0x81cc000
open("/etc/libsafe.exclude", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40020000
read(3, "/etc/tss2/server_linux\n", 4096) = 23
read(3, "", 4096) = 0
close(3) = 0
munmap(0x40020000, 4096) = 0
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
Ein COREDUMP wird nicht erzeugt ;)
Ideen?!
Simon
PS: Es handelt sich um die aktuellste TSS2 Version. ;) Und bis gestern lief alles reibungslos. Nach einem Restart des Systems (nach Aktualisierung der RPM Packete durch RedHat) tritt dieser Fehler auf. Aktualisiert wurden Dienste wie Xinetd und libraries GLIB etcpp. Ausserdem kam libsafe 2.0.16 hinzu und ersetzte die aeltere 1.3 Version. Libsafe ist eine MUSTHAVE library um etwaigen potentiellen Angreifern den Wind aus den Segeln zu nehmen, denn nicht immer sind Updates VOR den Attacken da. :)
Ich pers nehm an das es was mit libsafe zu tun hat, aber dann waere TSS2 das EINZIGE Programm was Probleme damit haette....
Hmm knapp 24 Stunden nach Posting nicht EINE Reply zum topic, man koennte fast meinen dieses forum sei nicht auf der site der developer....
Nichtsdestotrotz habe ich in den letzten 24 Stunden mehrfach mit dem libsafe Entwicklerteam Mails ausgetauscht und wir haben gemeinsam den crash von TS2 analysiert.
Und sind zu dem Schluss gekommen das es NICHT an libsafe liegen kann. Gruende:
(1) auf 3 Referenzsystemen wurde eigens TS2 (linux) installiert bei aktivierten libsafe und es gab kein Segmentation Fault. Zum Einsatz kamen 2.0.16 und 2.1.5 welches demnaechst erst released wird.
(2) bei eintrag in /etc/libsafe.exclude wurde die TS2 app ebenfalls ohne probs ausgefuehrt. Zwar wird libsafe auch bei eintrag in die exclude datei noch ausgefuehrt aber gibt alle funktionen sofort an die libc ab ohne sich weiter um die diversen funktionen zu kuemmern.
(3) lief es bei mir MIT libsafe auch ohne probleme nur Ploetzlich OHNE vorwarnung war der prozess tot und TS2 laesst sich nicht mehr starten. Damit hat TS2 nicht einmal 2 Tage uptime geschafft. Zum vergleich: TS1 laeuft bei uns seit monaten stabil.
Bei Interesse forwarde ich ernsthaft interessierten TS2 Entwicklern gerne die Mails zwischen mir und dem Libsafeteam und helfe natuerlich gerne bei der Einkreisung des Problems.
Aber dazu muesste mal jemand antworten! ;)
Simon
R. Ludwig
13-12-2002, 10:32
so wie du redest und schreibst koennte man fast meinen du haettest bei uns einen 24h sofort reaktions service gekauft.
der aktuelle linux server hat ein problem auf manchen systemen. wir sind schon dabei das problem einzukreisen wie auch aus einem englishen thread ersichtlich ist.
http://www.teamspeak.org/forums/showthread.php?threadid=2592
aber danke fuer deine muehen, falls wir dort naehere infos
brauchen werden wir dir eine anfrage senden.
Originally posted by R. Ludwig
so wie du redest und schreibst koennte man fast meinen du haettest bei uns einen 24h sofort reaktions service gekauft.
HEHE Nee, aber ich wusste nicht das man bei euch "Hoefflichkeit einer Antwort zumindest" erkaufen muss. :D
Aber um zum Kern zurueck zu kommen, also keine Hilfe erforderlich? HRHR Du hast dich immer noch nicht geaendert. Habe in diesem Forum noch nie eine einzige verneunftige Antwort auf ne Frage bekommen. Legt das Teil doch wenigstens unter BSD License frei wenn ihr schon spaeter kommerziellen Nutzen vorbehalten wollt. Aber so koennen wenigstens motiviertere Entwickler schneller und duetlich ergiebiger antworten.
Denn wirklich weitergeholfen hast du mir nicht. Das TS (auch schon TS1) auf "einigen Systemen" Probleme hat ist ja nun nichts wirkich neues. Aber die Frage ist doch vielmehr. Warum ERST nach 2 Tagen Uptime? Kommt TS2 mit den aktuellen GLIBC Updates von RH nicht klar? Ein wenig mehr Transparenz waer ganz "nett". :)
Simon
PS: und jetzt schaue ich mir dein Threadlink an auch wenn ich jetzt schon erahne das er mir bei meinem Problem nicht weiterhelfen wird. ;)
So, hab den Thread gelesen, aber wie befuerchtet nichts neues. Ausserdem beziehen deren Probleme sich ausschliesslich auf die neue Version. Diese habe ich aber erst installiert als das Problem "erstmalig" auftrat, zuvor hatte ich die vorgaengerversion laufen. ;)
Ein grossteil der postings sind jedeglich welche distribution und welche glibc und welche TSS version sie benutzen.
In meinem Fall bekomme ich aber einen gnadenlosen Segmentation fault, der nicht einmal mehr schafft nen Coredump zu schaffen, ansonsten wuerde ich einmal per gdb guckern was denn da konkret schief laeuft.
Auch wenns offtopic is: aber gibt es mal eine aktualisierte vollstaendige doku zum server? weil dort ja diverse einstellmoeglichkeiten existieren die nicht dokumentiert sind (Servertype grnudeinstellung fuer anonyme clients ...) :)
Ich wuerde gerne euch unterstuetzen dar ich zu den server betreibern (tss) der ersten stunde mitgehoere und damals als ts noch komplett unbekannt war die werbetrommel fuer euch (insbesonder bei BC und RW geplagten clans) geruehrt habe. :)
Ich habe also ein vitales Interesse daran das tss funktioniert ;)
wink
Simon
R. Ludwig
13-12-2002, 12:33
Auch wenns offtopic is: aber gibt es mal eine aktualisierte vollstaendige doku zum server? weil dort ja diverse einstellmoeglichkeiten existieren die nicht dokumentiert sind (Servertype grnudeinstellung fuer anonyme clients ...)
die doku wird es erst nach dem rc2 release geben, wir werden bis dahin das permission system komplett umschreiben. daher warten wir noch solange. die ganzen servereintraege der
ini datei fallen eh dann irgendwann weg. da wir ja auf sql
umsteigen (ob mit rc2 steht noch nicht fest).
wann der release sein wird? um den januar 2003
So, hab den Thread gelesen, aber wie befuerchtet nichts neues. Ausserdem beziehen deren Probleme sich ausschliesslich auf die neue Version. Diese habe ich aber erst installiert als das Problem "erstmalig" auftrat, zuvor hatte ich die vorgaengerversion laufen.
wir sind derzeit dabei das problem mit dem .31 server zu loesen. das steht wohl auch in zusammenhang mit verschiedenen libary versionen. vielleicht ist damit dein problem auch geloest. wenn nicht werden wir uns das natuerlich auch ansehen. wir haben
ja auch ein grosses intresse daran das ts bei jedem laeuft.
wir koennen dir in diesem moment einfach nicht sagen mach das und das dann funktioiert alles. du musst wohl oder uebel warten.
und es wird garantiert keinen geben der mehr motiviert ist als niels und ich um ts zu verbessern/perfektionieren. aber gut
ding will weile haben.
mfg
ralf
Originally posted by R. Ludwig
und es wird garantiert keinen geben der mehr motiviert ist als niels und ich um ts zu verbessern/perfektionieren.
Kaeme auf nen Versuch an :D
Nagut dann werde ich jetzt erstmal den Childprocess in der Prioritaet runtersetzen und warten bis ne Message kommt.
*IDLE und DaeumenchenDreh*
Simon
Tja da sich in den letzten Tagen irgendwie nichts hier tut in Richtung Problemloesung -- was ist denn nun?
Ich finde es schon etwas befremdlich warum ein Server sofern er sauber programmiert wurde gnadenlos wegknallt, nur weil man ein von RedHat zertifiziertes Update durchgefuehrt hat.
Dar ich bisher kein glibs 2.2.5 fuer RedHat 7.2 gefunden habe bzw dies nicht als zertifiziertes Update von RH angeboten wird, kommen natuerlich etwaige "Experimente" auf einem Livesystem nicht in Frage. ;)
Daher liegt mir an einer Loesung und Beseitigung des Problems. Ein blosses "Ignorieren" des Problems indem man einfach die Quelle des Uebels ignoriert und den Pfad der Systemkonsistenz verlaesst (Glibc 2.2.5 auf RH7.2 ohne Ruecksicht auf Verluste) ist nicht sinnvoll. Ich denke man sollte schon versuchen das Problem als solches zu loesen indem man die Quelle des uebels aufspuert und den "Bug" fixt. ;)
Gibt es evtl nen versteckten DEBUG Mode der mehr als ein Segmentation fault zustande bringt? Gar eine Art Prozessverfolgung so das ich sehe WO er konkret aussteigt? Natuerlich wuerde ein COREdump aehnliches offerieren. :)
Regards
Simon
PS: In Anlehnung an Raabs Hanfsong: Gebt den Source frei! (OS) :D
SatanClaus
19-12-2002, 14:51
Lange, du scheinst ja sehr viel Ahnung von Computern zu haben, allerdings solltest du dir auch mal überlegen, wie du mit den Entwicklern, von denen du ja schließlich was willst, umgehst...
Ich meien Ralf hat dir doch klar und deutlich gesagt, dass sie im Moment mit der Lösung beschäftigt sind und erstmal abwarten wollen, ob der nächste Patch deine Fehler behebt.
Naja und es ist doch klar, dass du mit deiner drängelnden Art eher weitere Schritte verlangsamst...
Naja, ich weiß nicht, welche Server-Version du ausprobiert hast, aber deinen ersten Post hast du am 12.12. gemacht, worin du sagst, dass du die neueste Version benutzt. Am 13.12. kam 2.0.18.32 raus... (Quicklink: http://www.teamspeak.org/download.php?op=viewdownload&cid=4 ) Da Ralf in seinem letzten Post noch von 2.0.18.31 redet, was am 13.12. wohl war, bevor die neue rauskam, und du dann im letzten Post darauf eingehst, dass sich anscheinend ja nix getan hat, vermute ich mal (sorry, wenn's falsch ist), dass du noch .31 verwendest.
Naja und wenn du helfen willst und dich nicht andauernd beklagen, dann könntest du ja in jedem Fall mal testen, ob's mit der neuen Version klappt und das hier posten :)
cu
SatanClaus
Originally posted by SatanClaus
Lange, du scheinst ja sehr viel Ahnung von Computern zu haben, allerdings solltest du dir auch mal überlegen, wie du mit den Entwicklern, von denen du ja schließlich was willst, umgehst...
Und diese "Entwickler" wollen schliesslich das ihr "Produkt" bugfrei ist und ein Erfolg wird. Die staendigen Probleme von TSS stehen dem aber im Weg.
Aber wenn du A**chkriecher gegenueber ehrlichen Leuten bevorzugst. Sorry kann ich net mit dienen. :)
Alles was ich verlange ist das man einen ernsthaften BUGREPORT auch ernsthaft bearbeitet und nicht mit Ausfluechten kommt und auf Threads verweist die ein Problem behandeln das nicht ansatzweise in der Symptomatik uebereinstimmt. Schliesslich behandelt niemand Krebs mit einer Salbe. ;)
Originally posted by SatanClaus
Ich meien Ralf hat dir doch klar und deutlich gesagt, dass sie im Moment mit der Lösung beschäftigt sind und erstmal abwarten wollen, ob der nächste Patch deine Fehler behebt.
Naja und es ist doch klar, dass du mit deiner drängelnden Art eher weitere Schritte verlangsamst...
Und ich habe doch "klar gesagt" das der Thread auf den er verwiesen hat mich nicht weiterbringt. Denn zum einen ist der dort geschilderte Bug ein GAENZLICH anderer UND ich sehe ehrich kein Grund warum tss2 crashen darf weil man glibc2.2.4-31 benutzt (patchversion von RH) RH bietet derzeit KEIN GLibc2.2.5 fuer RH7.2 an und somit eruebrigt sich jegliche Diskussion bezueglich testen von glibc2.2.5 auf RH7.2 ;)
Originally posted by SatanClaus
Naja, ich weiß nicht, welche Server-Version du ausprobiert hast, aber deinen ersten Post hast du am 12.12. gemacht, worin du sagst, dass du die neueste Version benutzt. Am 13.12. kam 2.0.18.32 raus... (Quicklink: http://www.teamspeak.org/download.php?op=viewdownload&cid=4 ) Da Ralf in seinem letzten Post noch von 2.0.18.31 redet, was am 13.12. wohl war, bevor die neue rauskam, und du dann im letzten Post darauf eingehst, dass sich anscheinend ja nix getan hat, vermute ich mal (sorry, wenn's falsch ist), dass du noch .31 verwendest.
Sicher das du meine Post richtig gelesen hast? auch die Timestamps?! Mein letztes Post war 5 Tage nach meinem vorletzten Post zu diesem Issue. Und du kannst davon ausgehen das saemtliche veroeffentlichten Patches getestet wurden. In uebrigen schrieb ich NACH den releases das sie nichts bringen, was aber im vornherein klar war, dar der Fokus bei den Patches auf einen gaenzlich anderen Bug basierte.
Originally posted by SatanClaus
Naja und wenn du helfen willst und dich nicht andauernd beklagen, dann könntest du ja in jedem Fall mal testen, ob's mit der neuen Version klappt und das hier posten :)
ich beklage mich solange solange hier nichts wesentliches passiert. ein segfault nach nem offiziellen RH up2date is ein wenig "peinlich" und ein upgrade auf 7.3 oder gar 8.0 ausschliesslich fuer tss2 sprengt jeden rahmen.
Was ich per Testen ausschliessen konnte OHNE das TSS Team, habe ich getestet und nur deshalb bin ich mir recht sicher das es sich um eine Inkompatiblitaet von TSS handelt. Die Frage ist nur WO und WARUM, dies kann ich aber unmoeglich ermitteln solange das TSS Team sich dieses schweren Bugs (SegFault ist wohl der groesste aller Bugs) nicht annimmt. Denn weder habe ich Zugang zum Source noch habe ich ne Info bisher ueber etwaige debug modi erhalten die evtl mehr als strace und ldd rauswerfen. Ein COREDUMP gibt es ja leider nicht sonst koennte man wenigstens dort ansetzen.
wink
Simon
Is ja schon traurig. Scheinbar werden hier nur DAU Anfragen bearbeitet. Die 1000ste Anfrage wie man nen Startupscript schreibt oder das Webinterface bedient.
Wie waers mal langsam damit den Bug sch anzunehmen, oder - wenn ihr dazu nicht in der Lage seid oder nicht Willens seid, entweder das Projekt wirklich OS zu machen oder nen CoreDump Code zu implementieren, so das man wenigstens den Ansatz ener Moeglichkeit hat, heruaszubekommen warum TS jegliche Funktion verweigert und sang und klanglos wegknallt.
Achja, das aeltere TS1 knallt genauso gnadenlos weg wie TS2, selbe Symptomatic, was mch nun auch glauben macht das es sich um etwas aelteres handeln muss.
Was das natuerlich ist, kann ich unmoeglich OHNE Hilfe der Entwickler hinbekommen.
Mal sehen ob ich irgendeine wie auch immer geartete Antwort in den naechsten "Stunden" bekomme. Ich glaub ja nicht dran...
Bei mir kommt genau der gleiche Fehler. Ich starte das Programm und es kommt sofort ein Segmentation Fault.
Die alte TS2 Version sowie TS1 liefen stets fehlerfrei.
Ich verwende Suse7.0 mit Kernel 2.4.18
Gruß,
Richard Lohwasser / mp
Originally posted by mp_
Bei mir kommt genau der gleiche Fehler. Ich starte das Programm und es kommt sofort ein Segmentation Fault.
Die alte TS2 Version sowie TS1 liefen stets fehlerfrei.
Ich verwende Suse7.0 mit Kernel 2.4.18
Gruß,
Richard Lohwasser / mp
Wenn uns schon die Entwickler nicht helfen - helfen wir uns Gegenseitig so gut es geht. ;)
Welche Version glibc hast du bei dir laufen? Bei mir laeuft 2.2.4-XX und ich habe diese Probs mit TS SEIT dem Security Update bei dem GLibC geupdated wurde. Dar es kein GLibC 2.2.5 fuer RH 7.2 gibt, konnte ich das noch nicht checkern. ;)
Hast du irgendwas geaendert AUSSER dem letzten TS Update (Libs, Kernel, ...)
wink
Simon
interessant. segfault beim ts2-server gibts bei mir auch beim starten, interessanterweise aber nicht reproduzierbar, sondern nur sporadisch und auch nur beim starten. wenn ich es dann noch einmal probiere funktionierts.
bei mir laeuft suse linux 8.1 pro mit kernel 2.4.18 und defaultpaketen.
R. Ludwig
08-01-2003, 15:33
Lange meister aller klassen.
check mal deine pm's
Originally posted by R. Ludwig
Lange meister aller klassen.
check mal deine pm's
HRHR Du nu wieder. ;)
Mach ich glatt mal, aber bitte demnaechst nur an meine emailaddy ;) Denn normalerweise benutze ich keine PMs in Foren, denn dann duerfte ich hunderte Foren regelmaessig abklappern. :)
@brain: welches libc hast du? defaultpackete bei suse ist nicht unbedingt jedem ein begriff. ;)
wink
Simon
@Lange
Vielleicht überlegst du mal, wo du hier bist, was du hier vom TSS Team bekommst und was du hier erwarten kannst !!!
Du bist hier in einem Forum zu Teamspeak ! - nicht aber in einem Developer Forum.
Du bekommst eine FreeWare ! - ich übersetze es für dich auch gerne = "Freie Waren" ! Das bedeutet du bekommst hier etwas umsonst, nicht weil du den Auftrag gegeben hast, nicht weil du darum gebeten hast und schon garnicht weil du dafür etwas bezahlt hast, sondern weil die Jungs "Lust" dazu hatten, IHR eigenes Voicetool zu programmieren und es später "freundlicher weise" der Öffentlichkeit auch zur Verfügung stellen.
Wenn du mal für etwas bezahlst, bekommst du auch bestimmt Support - dann hast du sogar ein gewisses Recht daran, aber hier, kannst du helfen das TeamSpeak besser und Fehlerfrei wird, aber du kannst nichts fordern.
Soviel dazu....
PS: Ich habe auf Debian "Woody" und SuSE 7.0, 7.1, 7.2 bisher noch keinen einzigen Absturz von TSS 2.0 erlebt !
R. Ludwig
09-01-2003, 16:41
Ich kann den fehler bei mir nicht reproduzieren.
kann mir irgendeiner, bei dem der fehler auftritt vielleicht
eine shell+ftp zu verfuegung stellen wo ich das austesten
kann ?
R. Ludwig
09-01-2003, 17:25
Ok thx Mp
R. Ludwig
09-01-2003, 19:09
All who have segmentation faults, please read
the attached file.
Originally posted by Jens L.
@Lange
...schwafel schwafel schwafel...
Soviel dazu....
PS: Ich habe auf Debian "Woody" und SuSE 7.0, 7.1, 7.2 bisher noch keinen einzigen Absturz von TSS 2.0 erlebt !
Glueckwunsch nimm Lolli und freu dich. Nur das die Distribution selbst nicht vielm sagt sondern wohl eher was den dein Softwarestand auf der jeweiligen Distri ist. Siehe: RH7.2 lief - Security-Fixes kamen - zertifizierte Updates unteranderem glibc auf 2.2.4 - Boom es lief nicht mehr. Ist aber immer noch RH7.2. ;)
Und nun kannst Du dich wieder deinen "Kunden" zuwenden und die 1000ste Frage zum Webinterface beantworten. Danke fuer Deine Zeit und Muehen.
Simon
Originally posted by R. Ludwig
All who have segmentation faults, please read
the attached file.
Hi R,
ich denke mal du sprichst auf den Passus hier an:
-- Some versions of the glibc loader can cause data corruption
during the dynamic loading and unloading of shared objects.
The result can be spontaneous segmentation faults in unrelated
programs. Kylix is particularly sensitive to this issue, and
will not install if that version of libc is present. This has
been reported to glibc's maintainers, who have incorporated a fix
in glibc 2.2. Systems that cannot upgrade to glibc 2.2 require
a patched version of glibc 2.1.2 or later.
Nun, das is sicherlich eine Moeglichkeit, aber ich gebe zu bedenken:
Die beziehen sich auf glibc2.1 und sagen das es mit 2.2 gefixed sei. Kann mir nicht vorstellen das der selbe bug erneut eingebaut wurde. Abgesehen davon haben einige mit 2.2.4 k den crash und nicht mehr mit 2.2.5. Andere wiederum haben es exakt umgekehrt. 2.24 laeufts 2.2.5 crash.
Wegen der Shell hast du ne PM ;) langesimon********* (msn), generallange (aim) oder im quakenet (#thecenter #usrangers) findest du mich fast immer ;)
wink Simon
Hi Ralf,
hier die Resultate die mich ein wenig nachdenklich stimmen:
[root@ns2 borpretest]# ./testsystem
Borland Kylix System Compatibility Test
Checking loader....OK
Checking kernel >= 2.2....OK
Checking libc >= 2.1.2....OK
Checking libjpeg >= 6.2.0....OK
Looks GOOD !!!
This system should be able to run Borland Kylix!
[root@ns2 borpretest]# ./borpretest
Borland Kylix System Compatibility Test
Segmentation fault
[root@ns2 borpretest]#
Wie Du sehen kannst, laeuft der eigentliche Test durch, aber borpretest selbst verabschiedet sich gnadenlos wieder mit nem Segmentation Fault.
Lustig finde ich auch das er meint 2.1.2 wuerde laufen ;) Das hatten wir ja schon besprochen. Tatsaechlich laeuft aber:
[root@ns2 borpretest]# rpm -q glibc
glibc-2.2.4-31
[root@ns2 borpretest]#
Tendenziel wuerd ich sagen let us blame Borland/Inprise ;) aber das wuerde uns net viel weiter bringen.
Aber auf jedenfall haben wir nun endlich Gewissheit das es sich tatsaechlich um eine Inkompatiblitaet zu glibc handelt.
wink
Simon
PS: Wenn du den Zugang zur Shell noch brauchst sag kurz Bescheid :)
N. Werensteijn
10-01-2003, 18:48
borpretest fails because the LD_LIBRARY_PATH enviroment var is not set (thats what the testsystem script is for).
This is probably not the reason why the ts server is failing. If it was, a simple ldd should reveal missing libraries.
N. Werensteijn
10-01-2003, 18:58
Sorry for the english, but my german is BAD.
I have been doing some more thinking. This libsafe stuff.. What does it do when a program does something that is illegal according to libsafe?
Originally posted by N. Werensteijn
borpretest fails because the LD_LIBRARY_PATH enviroment var is not set (thats what the testsystem script is for).
This is probably not the reason why the ts server is failing. If it was, a simple ldd should reveal missing libraries.
Stimmt, habs auch grad bemerkt. Aber die Kylix Segmentation Geschichte scheint so neu nicht zu sein. Bei Deja gibt es massenhaft aehnliche Geschichten. hmmm
wink Simon
Originally posted by N. Werensteijn
Sorry for the english, but my german is BAD.
I have been doing some more thinking. This libsafe stuff.. What does it do when a program does something that is illegal according to libsafe?
it does make a logentry to the secure log and it does KILL the process. Detailed information to libsafe youll find here: http://www.research.avayalabs.com/project/libsafe/
libsafe was the first thing i did verify. But the libsafe team did verify that libsafe does not "disturb" tss. As i said before. The segmentation faults by tss came when i had to update glibc and other daemons (xinetd,pine,...).
regards Simon
PS: In case you are interested in, i may send you the mails between the libsafe team and myself. ;) just gimme a note if youre interested in (sl AT polynaturedesign DOT com).
Hi,
just for your information. a snapshot out of my secure logfile:
Dec 12 05:48:34 ns2 libsafe.so[1654]: Libsafe version 2.0.16
Dec 12 05:48:34 ns2 libsafe.so[1654]: Detected an attempt to write across stack boundary.
Dec 12 05:48:34 ns2 libsafe.so[1654]: Terminating /root/libsafe/libsafe-2.0-16/exploits/t1.
Dec 12 05:48:34 ns2 libsafe.so[1654]: uid=0 euid=0 pid=1654
Dec 12 05:48:34 ns2 libsafe.so[1654]: Call stack:
Dec 12 05:48:34 ns2 libsafe.so[1654]: 0x4001a871 /lib/libsafe.so.2.0.16
Dec 12 05:48:34 ns2 libsafe.so[1654]: 0x4001a97a /lib/libsafe.so.2.0.16
Dec 12 05:48:34 ns2 libsafe.so[1654]: 0x804865b /root/libsafe/libsafe-2.0-16/exploits/t1
Dec 12 05:48:34 ns2 libsafe.so[1654]: 0x804866e /root/libsafe/libsafe-2.0-16/exploits/t1
Dec 12 05:48:34 ns2 libsafe.so[1654]: 0x40055652 /lib/i686/libc-2.2.4.so
Dec 12 05:48:34 ns2 libsafe.so[1654]: Overflow caused by strcpy()
if libsafe would accidently "think" that tss does sumthin illegal it would have been found here.
regards
Simon
N. Werensteijn
10-01-2003, 19:35
I just installed libsafe and now i get segfault too :(
So we found the reason, now the problem
N. Werensteijn
10-01-2003, 19:42
strace:
execve("./server_linux", ["./server_linux"], [/* 34 vars */]) = 0
brk(0) = 0x80be1a4
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x126000
open("/etc/ld.so.preload", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=18, ...}) = 0
old_mmap(NULL, 18, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0x127000
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\36 0\17"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=22019, ...}) = 0
old_mmap(NULL, 20240, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x128000
mprotect(0x12c000, 3856, PROT_NONE) = 0
old_mmap(0x12c000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x3000) = 0x12c000
close(3) = 0
munmap(0x127000, 18) = 0
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=69713, ...}) = 0
old_mmap(NULL, 69713, PROT_READ, MAP_PRIVATE, 3, 0) = 0x12d000
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\20 0D\0"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=105551, ...}) = 0
old_mmap(NULL, 86880, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x13f000
mprotect(0x14d000, 29536, PROT_NONE) = 0
old_mmap(0x14d000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xd000) = 0x14d000
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\32 4\34"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=14550, ...}) = 0
old_mmap(NULL, 12456, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x155000
mprotect(0x157000, 4264, PROT_NONE) = 0
old_mmap(0x157000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x157000
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\0t\2 27\1"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1402939, ...}) = 0
old_mmap(NULL, 1216544, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x159000
mprotect(0x278000, 40992, PROT_NONE) = 0
old_mmap(0x278000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x11e000) = 0x278000
old_mmap(0x27e000, 16416, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x27e000
close(3) = 0
munmap(0x12d000, 69713) = 0
getrlimit(0x3, 0x7ffff8dc) = 0
setrlimit(RLIMIT_STACK, {rlim_cur=2044*1024, rlim_max=RLIM_INFINITY}) = 0
getpid() = 31349
uname({sys="Linux", node="cc21338-a.ensch1.ov.nl.home.com", ...}) = 0
rt_sigaction(SIGRTMIN, {0x147984, [], 0x4000000}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x147a24, [], 0x4000000}, NULL, 8) = 0
rt_sigaction(SIGRT_2, {0x147b40, [], 0x4000000}, NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [RTMIN], NULL, 8) = 0
_sysctl({{CTL_KERN, KERN_VERSION}, 2, 0x7ffff6e4, 32, (nil), 0}) = 0
readlink("/proc/self/exe", "/home/niels/test_old/tss2/server_linux", 4095) = 38
brk(0) = 0x80be1a4
brk(0x80be1d4) = 0x80be1d4
brk(0x80bf000) = 0x80bf000
open("/etc/libsafe.exclude", O_RDONLY) = -1 ENOENT (No such file or directory)
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
this interrests me:
open("/etc/libsafe.exclude", O_RDONLY) = -1 ENOENT (No such file or directory)
I am not yet formiliar with libsafe.
Do you have this file? If so, what happens if you put server_linux in the exclude?
N. Werensteijn
10-01-2003, 19:55
Ok last for now:
With libsafe enabled, i can't even start kylix (the programming enviroment).
Something is seriously wrong with libsafe + kylix (applications).
N. Werensteijn
10-01-2003, 20:15
Ok i did some debugging.
The error is in this procedure, in the dlerror call.
This is especialy weird because that is a system call ?
This routine is part of all kylix programs. It is called before any code of the actualy code is called
procedure InitUnwinder;
var
Addr: Pointer;
begin
{
We look to see if we can find a dynamic version of the unwinder. This
will be the case if the application used ShareExcept.pas. If it is
present, then we fire it up. Otherwise, we use our static copy.
}
Addr := dlsym(0, '_BorUnwind_RegisterIPLookup');
if Addr <> nil then
begin
Unwinder.RegisterIPLookup := Addr;
Addr := dlsym(0, '_BorUnwind_UnregisterIPLookup');
Unwinder.UnregisterIPLookup := Addr;
Addr := dlsym(0, '_BorUnwind_RaiseException');
Unwinder.RaiseException := Addr;
Addr := dlsym(0, '_BorUnwind_DelphiLookup');
Unwinder.DelphiLookup := Addr;
Addr := dlsym(0, '_BorUnwind_ClosestDelphiHandler');
Unwinder.ClosestHandler := Addr;
end
else
begin
dlerror; // clear error state; dlsym doesn't
Unwinder.RegisterIPLookup := _BorUnwind_RegisterIPLookup;
Unwinder.DelphiLookup := _BorUnwind_DelphiLookup;
Unwinder.UnregisterIPLookup := _BorUnwind_UnregisterIPLookup;
Unwinder.RaiseException := _BorUnwind_RaiseException;
Unwinder.ClosestHandler := _BorUnwind_ClosestDelphiHandler;
end;
end;
Originally posted by N. Werensteijn
Ok last for now:
With libsafe enabled, i can't even start kylix (the programming enviroment).
Something is seriously wrong with libsafe + kylix (applications).
To be more acurate: Kylix has serious problems with preloaders.
libsafe.exclude is an exclude list of applications where libsafe shall not be active!. In case kyix (or tss) is there enlisted libsafe just does nothin. I tried to send you the mails of the libsafe team which had already checked this issue, but your mailserver refused to accept the attachment (the mail).
here a short snapshot of their mail. i think it talks for itself: Timothy K Tsai (libsafe team) wrote
I've downloaded the server_linux executable myself and tried to play around with it.
If you use /etc/libsafe.exclude, the libsafe library will still be preloaded, and it will still intercept the same functions, but it will immediately call the original libc functions, which means that it effectively does nothing.
The curious thing for me is that when I set the server_linux pathname in /etc/libsafe.exclude, everything works, and there is no segfault. In fact, even if I don't set anything in /etc/libsafe.exclude, if I include some dummy libc calls in the libsafe code, then server_linux works. My first thought was that it's possible that server_linux has a malloc bug, but that is not something that I can confirm.
He also said that he had used an unofficial libsafe version for testing. But i have researched a bit. It seems that Kylix has trouble with ANY kind of preloaders. Dont ask me why, but if you investigate a little bit on the usenet you will find a lot of stuff havin exactly the very same issue. not libsafe and tss but any preloader and kylix (and programs made with kylix).
Did you already read those technical documentations at the link i provided you?.
regards
Simon
Oops i have overseen a question - sorry. If i put server_linux into the exclude list. libsafe does not touch server_linux. But tss does still crash. although libsafe doesnt do anything. /timothy already stated that. ;) The only difference is that a library is preloaded. But why has kylix such a problem with that?
regards Simon
PS: just found a nother thread from july2002 who has the same symptom: http://www.teamspeak.org/forums/showthread.php?s=&threadid=271&highlight=segmentation
N. Werensteijn
11-01-2003, 10:43
See my last post.
As part of any kylix program (and apparently kylix) the InitUnwinder procedure is called during startup.
the whole thing sigfaults when the dlerror routine tries to do a compare on adress 0x00000000 (compsb i think the asm opcode was)
Since dlerror takes no parameters, i am at a loss what could be wrong. My first guess would be something is wrong with libc / libsafe.. But i dont suppose it is that easy :)
When libsafe is not loaded, the compare does not happen on adress 0x00000000
which link are you referring to?
Originally posted by N. Werensteijn
See my last post.
Since dlerror takes no parameters, i am at a loss what could be wrong. My first guess would be something is wrong with libc / libsafe.. But i dont suppose it is that easy :)
Damn right. ;) Because if libsafe would be responsible for this kylix-bug then other application would have the very same bug, right? But in the moment only Kylix AND kylix-made-applications do have this bug.
Originally posted by N. Werensteijn
When libsafe is not loaded, the compare does not happen on adress 0x00000000
thats what i wrote. if NO libarary is being preloaded, kylix has no trouble but the second you preload anything you risk segmentation fault. Just search the usenet (google) for: kylix segmentation - there are thousands of hits.
I still think its an incompatibility between Kylix <-> preloading <-> libc . I think only Borland/Inprise could fix it. We can just try to workaournd a little bit. ;)
I have - of course - read your post about InitUnwinder. Is there any way to rewrite (overwrite) this procedure for fixing this issue? Dont know the kylix capabilities that good as you. What does Borland/Inprise say to this issue. Well, thousands of ppl havin trouble with their product, so there is maybe a solution anywhere in their developer-forums. Silly Question - i know - but have you checked them lately?
Originally posted by N. Werensteijn
which link are you referring to?
what link do you talking about? i thought i have posted all links i talked about.... in case you talking about the "link i provided to you" i talked about the libsafe link. there you find detailed information abut libsafe - how it works and so on. ;)
regards Simon
N. Werensteijn
11-01-2003, 20:32
Well, i might be able to recompile the whole lot with a workaround. Might be a bit tricky tough :) Ill give it a try later.
As for reporting..
Borland have this great util called qualityCenter (or qualityService). I posted 2 huge bugs on it 3 months ago.. Still no reaction :( That pisses me off a little :p But i will report this.
Still, i wonder how kylix can influence internal variables in glibc. (since dlerror takes no parameters)
My experience with Borland/inprise is the same. I have reported several bugs within JBuilder Enterprise Suite (4 when i remember correctly). Same "reaction" - nothing.
So this behavour seems usual for borland/inprise. ;)
but back to topic. well nobody knows what these developers did but it seems to ran terribly wrong.
as i said before. if you need ANYTHING just gimme a note. ;)
regards
Simon
i don't think it has anything to do with libsafe. i don't use it and i get the segfault too
Originally posted by mp_
i don't think it has anything to do with libsafe. i don't use it and i get the segfault too
Agree, but what im interested in. LD_PRELOAD? anything? e.g. any intrusion detection system or an active virus-scanner?
regards Simon
PS: Silly Question - but - did it made a coredump? if so what does gdb say?
vBulletin® v3.7.0, Copyright ©2000-2008, Jelsoft Enterprises Ltd.