*** glibc detected *** double free or corruption (!prev): [...]

[Jan 'RedBully' Seiffert]

Stefan U. Hegner wrote:
> Moin Max,
> 
> Maximilian Wilhelm schrieb:
>> Am Thursday, den  1 May hub Stefan U. Hegner folgendes in die Tasten:
>>   
>>> wollte gerade mit mondoarchive (v2.2.0-881; etch-amd54) ein Backup
>>> ziehen, da bekam ich den o.g. Fehler:
>>>
>>>     *** glibc detected *** double free or corruption (!prev): 0x00000000005510a0 ***
>>>     
>> Das kann ein einfacher Programmierfehler sein.
>>   
> Finde ich nicht wahrscheinlich bei einem Paket aus Etch, oder? Es sei
> denn, es knallt nut unter ganz bestimmten Rahmenbedingungen.

Ein "Double Free" riecht nach Programmierfehler. Ob in Etch oder 
sonstwo. Ja, es kann ein gekiptes Bit durch br0ken Speicher als Ursache 
in Frage kommen, aber es ist unwarscheinlich. Denn da ist die Sache mit 
den "bestimmten Rahmenbedingungen":
  - Du hast Fenster/Aktionen in einer Reihenfolge auf und zu gemacht, an 
die der Entwickler nicht gedacht hat (nie ausprobiert hat).
  - Dank heutzutage Multicore ueberall ist SMP immer heufiger, eine 
RaceCondition kann einem echt den Tag versauen, sie sind nur sehr 
Laufzeitabhaengig und nur schlecht Reproduzierbar, meist....
  - Du stolperst eigenlich in einen anderen Bug beim Verarbeiten deiner 
Daten, Double Free ist nur das Symptom weil irgendwo Speicher 
ueberschrieben wurde.

Oder eben: Ja, du hast einen Kaputten RAM-Riegel.
Und damit das Programm reproduzierbar abstuerzt muss nach dem Start 
deines Multiuser Multitasking Systems das Programm IMMER an die gleiche 
PYSIKALISCHE Adresse geladen werden. Dort aendert der RAM-Fehler eine 
Pointer immer so, das er mit einem anderen Zeiger uebereinstimmt, so das 
beim Freigeben der beiden (der orginale und der veraenderte) die libc 
noekelt.

Nebenbei: Die libc beschwert sich ueber "double free _or corruption_" 
(betonung von mir). Es kann auch sein das eben irgendwo irgendwas wild 
in den Speicher schreibt, was auch eher nach Progfehler riecht.
Andres Hinweiss auf Valgrind ist da auch Sachdienlich. Ausser die 
Entwickler selbst haben das noch nie benutzt, dann kann es sein das 
einem ein Haufen Fehler aus Nebenschauplaetzen den Blick vernebeln.

>> Sprichst Du C?
>>   
> Ei spiiek unly bokken C.

"Aber da kann man doch was machen"

>> Ich hab mal nen kleines - eigentlich sinnloses - Programm gebaut,
>> bei dem es auch knallt.
>>   
> [...]
>> Optimalerweise solltest Du dann sehen können, wo es geknallt hat.
> So weit so gut. - Aber was ist der Sinn davon? Dann habe ich nochmal so
> einen Fehler nachgebaut, und dann?

Dann hast du nicht ganz zu ende gelesen.
Dann kannst du mal in einer einfachen Beispiel versuchen, mit hilfe des 
GDB ein paar informationen da rauszuziehen und das Problem zu verstehen.
Mit den in dieser Lektion kennengelernten Werkzeugen kannst du dann mal 
in das Orginalproblem reinschnueffeln, und vieleicht genauer 
beschreiben, was passiert (Denn der abgeschnittene Trace aus dem Orginal 
ist nicht besonders Hilfreich: Hilfe, es ist was kaputt, und zwar ... )

> Oder willst Du mir sagen, dass das
> Problem möglicherweise außerhalb von Mondoarchive liegt und mir Dein
> Programm helfen soll, jenes genauer zu lokalisieren?
> 
> Gruß & Danke!
> 
> Stefan.
> 
Gruss
	Jan

> 


-- 
"Da koennen sie waehlen wie sie wollen.
Die sagen das ist Demokratie,
ich glaube das ist wie Scheisse am Schuh..."
		 Volker Pispers