Segmentation Fault

[Lange]

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\2 0\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\000 0\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\ 36\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\ 307\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....

[Lange]

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]

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/show...?threadid=2592

aber danke fuer deine muehen, falls wir dort naehere infos
brauchen werden wir dir eine anfrage senden.

[Lange]

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.

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.

[Lange]

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]

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

[Lange]

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

Nagut dann werde ich jetzt erstmal den Childprocess in der Prioritaet runtersetzen und warten bis ne Message kommt.

*IDLE und DaeumenchenDreh*

Simon

[Lange]

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)

[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...

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.ph...download&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

[Lange]

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.ph...download&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

[Lange]

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...

[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

[Lange]

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

[Brain]

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]

Lange meister aller klassen.

check mal deine pm's