Zitat von Zacherl:

Ich glaube du leakest den Speicher von vProcList , falls bFound = True .

Auf jeden fall ist das so.

Beim beenden der Anwendung bekomme ich ein Speicherleck Meldung von der vProcList angezeigt.
Glaube aber das ist deshalb weil die Pointer verschoben werden wie oder wo auch immer.

Denn ich gebe die ja frei FreeAndNil(vProcList);
Aber es fruchtet nicht die Speicherlecks kommen trotzdem.

Zitat:

Kannst du da denn nicht mal genauer reinsteppen mit dem Debugger und eine genaue Stelle nennen, an der es zum ersten Mal kracht nach dem Event?

Es kracht sobald ich irgendwo wieder auf TAudioVolume zugreife.
Die Zeile ist diese aber die macht nichts besonderes was den Fehler auslösen könnte.

zusammenfalten · markieren

Delphi-Quellcode:

function TAudioVolume.AudioSessionInfo(SessionIndex: integer): TAudioSessionInfo;
var
  Lbl: TLabel;
  tmpStr: string;
  bNull: BOOL;
  i: integer;
begin
  Result.ActiveSession := '';
  Result.DisplayName := '';
  Result.StateSession := '';
  Result.IconPath := '';
  Result.SessionIdentifier := '';
  Result.ProcessID := '';
  Result.IsSystemSoundsSession := -1;
  Result.SessionGuid := StringToGUID('{00000000-0000-0000-0000-000000000000}');
  Result.Device := nil;
  Result.PID := 0;

  bNull := False;

  tmpStr := ExtractFileExt(FAudioSessionInfo.DisplayName); \\ <<<<<<< Hier kracht es
  if Length(tmpStr) > 1 then
    tmpStr := ChangeFileExt(FAudioSessionInfo.DisplayName, '')
  else
    tmpStr := FAudioSessionInfo.DisplayName;

Ok
FreeAndNil(vProcList); steht an falscher stelle muss eine Zeile tiefer. Danke.
Werde mal schauen ob das mein Problem behebt.

Die Leaks sind behoben aber das Problem bleibt bestehen.
Habe nur diese beiden. Siehe Anhang.


gruss

Zitat:

Denn ich gebe die ja frei FreeAndNil(vProcList);

Aber nur, wenn du den Prozess vorher nicht gefunden hast, sonst nicht.

Zitat von mkinzler:

Zitat:

Denn ich gebe die ja frei FreeAndNil(vProcList);

Aber nur, wenn du den Prozess vorher nicht gefunden hast, sonst nicht.

Richtig. .Danke!
Deshalb habe ich sie eine Zeile tiefer gesetzt Fehler ist behoben was die Leaks betrifft.
Die Pointer spielen aber immer noch verrückt.

Die anderen Speicherlecks.. siehe Shots.

gruss

Zitat von dummzeuch:

Hast Du schon ermittelt, welche Speicherfreigabe die Exception auslöst? Wenn ja, mal im ensprechenden Destructor einen Breakpoint setzen und schauen, von wo und wie oft er aufgerufen wurde.

Keine Speicherfreigabe löst den Fehler aus.
Sondern der nächste darauffolgende zugriff auf TAudioVolume.

gruss

Ich liege hundert pro eh falsch aber gesagt haben mag ichs mal.
Setze doch mal einen BP vor Zeile FOnSessionStateEvent(self, NewState); und stepp dich da mal rein ob das alles seine Richtigkeit hat. Noch kommt mir das Self komisch vor, aber ich kann mich, wie so oft bei Dir, total irren.

Und verträgt Result.IsSystemSoundsSession :-1; einen negativen Wert ?

Zitat:

tmpStr := ExtractFileExt(FAudioSessionInfo.DisplayName); \\ <<<<<<< Hier kracht es

existiert denn FAudioSessionInfo.DisplayName zu diesem Zeitpunkt?
Wegen Result.DisplayName := '';
Lass Dir doch an dieser Stelle ne MessageBox anzeigen was du da so für Daten im Speicher hast.

bekomme es nicht geregelt. egal.
Habe noch andere Projekte.

gruss

Wenn du doch nochmal reinschauen willst: Was sagt denn der Debugger zu den Werten von Self , FAudioSessionInfo , etc? Steht da unter Umständen vielleicht schon "Müll" drinnen? Nur mit statischen Informationen ist es hier leider recht schwer die Fehlerquelle zu ermitteln.

Zitat von Zacherl:

Wenn du doch nochmal reinschauen willst: Was sagt denn der Debugger zu den Werten von Self , FAudioSessionInfo , etc? Steht da unter Umständen vielleicht schon "Müll" drinnen? Nur mit statischen Informationen ist es hier leider recht schwer die Fehlerquelle zu ermitteln.

Nein self ist die TAudioVolume Classe da steht kein Müll drin.

self und AudioSessionInfo siehe Anhang.
Ist schade aber so kann ich das Projekt nicht fertig stellen. sorry.
Ich habe zu wenig Erfahrung mit Threads so das ich den Fehler selber analysieren könnte.
Der Debugger ist in dem Fall nicht Hilfreich.

Ganz umsonst war das Projekt nicht habe 1>2 Fehler in meiner Library beheben können und eine neue Funktion addiert um zu vor erstellte
Kombinierte Objekte in einem rutsch zu löschen.

markieren

Delphi-Quellcode:

// Alle Objekte die mit diesen verbunden sind löschen
for I := 0 to Length(AudioVolumeArr) - 1 do
  gSprSession.GD_DeleteLinkedObject(succ(ID_BVOLUME) + i); // neue Funktion

EDIT:
Habe meine Funktion nochmal optimiert ändert aber nichts an meinem Pointer Problem doch das hier (AudioVolumeArr[M].Free;)

zusammenfalten · markieren

Delphi-Quellcode:

procedure TMainClass.SessionStateEvent(Sender: TCustomAudioVolume; NewState: integer);
var
  IntI, K, M: integer;
  ProcId: DWORD;
  vProcList: TProcesses;
  bFound: BOOL;
begin

  bFound := false;

  for IntI := 0 to Length(AudioVolumeArr) - 1 do
  begin
    if AudioVolumeArr[IntI] = Sender then
    begin
      ShowMessage(AudioVolumeArr[IntI].AudioSessionInfo(IntI).DisplayName + #13#10 +
        'Index ' + IntToStr(IntI) + ' hat jetzt State ' + IntToStr(NewState));

      ProcId := StrToInt(AudioVolumeArr[IntI].AudioSessionInfo(IntI).ProcessID);

      if (ProcId <> 0) and (NewState = 0) then
      begin
        // ProcList initialisieren
        vProcList := TProcesses.Create;
        // Prozesse einlesen
        vProcList.ReadSystem;
        // prüfen ob aktiver prozess existiert
        for K := 0 to vProcList.Count - 1 do
          if vProcList[K].ID = ProcId then
          begin
            bFound := true;
            // Raus hier
            break;
          end;

        if not bFound then
        begin
          // Timer deaktivieren
          KillTimer(HSprMaster, ID_MRENDER);
          // Alle Objekte die mit diesen verbunden sind löschen
          for M := 0 to Length(AudioVolumeArr) - 1 do
          begin
            gSprSession.GD_DeleteLinkedObject(succ(ID_BVOLUME) + M);
            // TAudioVolume freigeben
            AudioVolumeArr[M].Free;
          end;
          // Array löschen
          SetLength(AudioVolumeArr, 0);
          // Session erstellen
          CreateSession;
          // Window aktualisieren
          gSprSession.GI_UpdateWindow(HSprSession, false);
          // Timer aktivieren
          SetTimer(HSprMaster, ID_MRENDER, 60, nil);
        end;
        // Prozessliste löschen
        vProcList.Clear;
        // Prozessliste freigeben
        FreeAndNil(vProcList);
      end;
    end;
  end;
end;

gruss

Ahchso, ne ich meinte eigentlich das Self innerhalb von TAudioVolume.AudioSessionInfo . Also dann, wenn es kracht. Meine Vermutung war halt, dass hier schon irgendwelche Zeiger (vlt. sogar Self ) ins leere laufen.

Zitat von Zacherl:

Ahchso, ne ich meinte eigentlich das Self innerhalb von TAudioVolume.AudioSessionInfo . Also dann, wenn es kracht. Meine Vermutung war halt, dass hier schon irgendwelche Zeiger (vlt. sogar Self ) ins leere laufen.

Es gibt kein self innerhalb TAudioSessionInfo.
TAudioSessionInfo ist ein Record.

Vielleicht bin ich auch zu dumm zu verstehen was du meinst.
Habe bald den Eindruck als wenn die AudioSes.dll (Win7) selbst fehlerhaft ist wenn hier schon ein Speicherleck angezeigt wird.

gruss