Heap Fehler? Applikation läuft weiter...

[mekakic]

Ich verwende ein C Lib in meinem C++ Programm und beobachte ein Verhalten, was ich sehr eigenartig finde. Die C Lib wird meines Wissens richtig initialisiert und wenn es ans eingemachte geht, schlägt bei erstmaligem Call eine "Unbehandelte Ausnahme" bei mir im Debugger auf. Der Debugger springt dann mit seinem Ausführungskontext (der grüne Pfeil im VS Debugger:)) zum return einer völlig anderen Methode der Klasse, die gar nicht aufgerufen wird oder wurde. Da kann man dann unterbrechen oder weiterlaufen lassen. Die Applikation läuft dann auch weiter und scheint das richtige zu tun, was mir aber gefährlich vorkommt. Danach ist allerdings beim Debugger die aktuelle Codeposition (wo man sich gerade befindet) nicht immer richtig und danach hatte ich auch schon einige Male einen Visual Studio Absturz.

Die Operationen der C-Lib hab ich in einem try{
//call
} catch(...)
{
//
}
Block drin ... wo normalerweise Speicherfehler auch drin gelandet sind, aber hier passiert nichts. Auf der Konsole wird nur ausgegeben:
HEAP[app.exe]: Invalid Address specified to RtlFreeHeap( 01BB0000, 0444006B )
Unbehandelte Ausnahme bei 0x7c91120e in app.exe: Benutzerhaltepunkt.

Hat jemand eine Idee, was da schief läuft?

[Trap]

Es kann sein, dass die C-Lib SEH benutzt: http://msdn.microsoft.com/en-us/library/ms680657(v=vs.85).aspx

Das implementiert auch Exception-Handling, arbeitet aber mit try/catch von C++ nicht zusammen.

[mekakic]

Weiß ich nicht. Bei der C-Lib handelt es sich um ffmpeg und SEH scheint eine Windows Sache zu sein? Wenn man sich die Dokumentation von ffmpeg durchliest, scheint Windows für die eher eine Notplattform zu sein und es ist auch nur mit Hürden möglich das überhaupt mit VS zu nutzen oder zu kompilieren. SEH würde mich da überraschen.

[mekakic]

Das Problem schien gewesen zu sein, dass irgendwie Allokation und Freigabe von Speicher in und außerhalb der Lib das Programm aus dem Tritt gebracht haben.

Der Speicher wurde vom Debug Heap mittels "new" geholt und dann in der Lib wohl mittels "free()" wieder freigeben. Ist das ein Problem? Ich könnte mir vorstellen, dass es andersherum Probleme gibt (vom Release Heap holen, vom Debug Heap freigeben) weil evtl. noch irgendwelche Debuginformationen mit freigegeben werden müßten aber so rum?

[Trap]

Speicherallokation und Deallokation müssen immer mit zueinander passenden Operationen passieren. Die speichern schließlich zusätzliche Verwaltungsdaten, damit das Freigeben einfach nur mit der Adresse möglich ist und im Normalfall ist bei jeder Variante die Art die Daten zu speichern unterschiedlich.

Die Deallokation liest also irgendwelches Zeugs, interpretiert es wie normal und benutzt das weiter für die Speicherverwaltung.

Das geht ja schon bei new->delete[] oder new[]->delete nicht...