[gelöst] glibc free() problem

Hallo Forum!

ich habe ein merkwürdiges (und ernstes) Problem:

Ich bekomme bei vielen Befehlen die Fehlermeldung:

*** glibc detected *** free(): invalid next size (normal): 0x080ed298 ***
Abgebrochen

So kann ich z.B. mit dem Befehl “ls” mir den Inhalt der meisten Verzeichnisse Anzeigen lassen, nicht jedoch des Verzeichnisses /home (ich vermute da hier ca. 400 Unterverzeichnisse sind).

Es kann sich nicht um einen Dateisystemfehler handeln, da /home in diesem Fall im rootfs liegt (xfs, clean).

Die gleiche Fehlermeldung tritt z.B. bei dem Befehl “smbstatus -b” auf, wenn Benutzer angemeldet sind. Sind keine Benutzer angemeldet, läuft der Befehl fehlerfrei durch.

Auch einige init Skripte brechen mit der Fehlermeldung ab, so etwa “/etc/init.d fetchmail start”

Das System läuft für die Benutzer noch normal, allerdings funktioniert mein Backup nicht mehr, was die Sache etwas heikel macht.

Kann mir irgendwer einen Tip geben?

Das Problem ist ohne irgendeine Änderung am System irgendwann aufgetreten.

UCS Version ist 2.0.1 mit allen updates

Mit besten Grüßen

Gerd Wilhelm

Hallo,

[quote=“gwilhelm”]
ich habe ein merkwürdiges (und ernstes) Problem:

Ich bekomme bei vielen Befehlen die Fehlermeldung:

*** glibc detected *** free(): invalid next size (normal): 0x080ed298 ***[/quote]

Das ist ein neues Verhalten von glibc. Wenn Programme ungültige Aufrufe von free() durchführen wird dies mit der berichteten Fehlermeldung dokumentiert und das Programm abgebrochen (abort()). Dieses Standardverhalten kann man mit der Umgebungsvariable MALLOC_CHECK_ beeinflusst werden.

Durch Setzen der Variable auf den Wert “1” wird zwar noch die Fehlermeldung ausgegeben, aber das Programm weiter ausgeführt. Durch den Wert “0” werden diese Fehler komplett ignoriert.

Prüfen Sie bitte einmal, ob Sie durch Setzen der Variable die Programme wieder ausführen können. Beispielsweise:

export MALLOC_CHECK_=0 ls -l

Sollte dies Ihr Problem beheben können Sie die Variable auch in /etc/profile bzw. in dem zugehörigen Univention Configuration Registry-Template setzen.

Mit freundlichen Grüßen
Andreas Büsching

Hallo Forum, hallo Herr Büsching!

danke für den Tip. Die Programme scheinen jetzt in der Tat einen Tick weiter zu laufen:

export MALLOC_CHECK_=1 ls malloc: using debugging hooks *** glibc detected *** free(): invalid pointer: 0x080f2570 *** *** glibc detected *** malloc(): memory corruption: 0x080f2d78 *** Speicherzugriffsfehler

Google vermutet bei obiger Fehlermeldung eine unpassende libc6 Version. Ich habe allerdings nur passende Univention Quellen verwendet. Libc6 ist Version 2.3.6.ds1-13.18.200710190727

Beste Grüße

Gerd Wilhelm

Hallo,

In einem Test konnte ich auf einem UCS 2.0 System das Problem nicht reproduzieren. Dafür habe ich ls in einem Verzeichnis mit 600 Unterverzeichnissen aufgerufen. Haben Sie eventuell Anpassungen auf dem System vorgenommen? Wurde das System von einer älteren UCS Version aktualisiert? Wenn ja, wurde das Update ohne Fehler beendet? Wurden auf dem System zusätzliche Paket installiert, die nicht für UCS 2.0 gebaut wurden (evtl. für Debian Etch)?

Hilft es eventuell einen strace durchzuführen um weitere Anhaltspunkte auf die Ursache für das Problem zu bekommen?

strace -f -o ls.strace ls

Anschließend ist die Ausgabe von strace in der Datei ls.strace zu finden.

Mit freundlichen Grüßen
Andreas Büsching

Das Problem ist gelöst.

Mir ist aufgefallen, dass das Problem im runlevel 1 nicht auftritt. Daher habe ich nach und nach alle Dienste abgeschaltet, und so herausgefunden, dass ohne ldapserver das Problem nicht auftritt.

Dann habe ich festgestellt, dass der Befehl

getent group

bei einer bestimmten Gruppe abbricht. In dieser Gruppe befand sich ein Mitglied, zu dem der Benutzer seltsamerweise im univention directory Manager nicht angezeigt wurden.

Das Homeverz. des Benutzers lies sich nicht anzeigen.

Nach dem löschen des Benutzers über die Kommandozeile mit univention-directory-manager läuft das gesamte System wieder mormal.

Hurra!

Beste Grüße

Gerd Wilhelm

Mastodon