was macht System.IsMultiThread genau?

[EWeiss]

Kann mir jemand erklären was der aufruf

Delphi-Quellcode:

System.IsMultiThread := true;

im System genau bewirkt?

Mein problem ist das jemand nicht in der lage ist BassVis mit seiner anwendung vernünftig zu debuggen.
Wäre es möglich, das, wenn diese zeile sich nicht in der DLL befindet es beim Debuggen
in fremden Anwendungen zu problemen kommen kann?

Alles funktioniert zu 98% nur jetzt nervt mich jemand mit diesen Problem.

Ich habs mal eingefügt .. nur lößt das mein problem ?

Delphi-Quellcode:

  procedure LibraryProc(Reason: integer);
  begin
    case (Reason) of
      DLL_PROCESS_ATTACH:
      begin
        BassHandle := LoadLibrary('bass.dll');
        if (BassHandle = 0) then
        begin
          MessageBox(0, 'Unable to load ''bass.dll''' + #13#10 + 'Halting the library process', 'Fatal Error!!', MB_ICONERROR);
          ExitCode := 1;
          Exit;
        end;

        BassFuncs := GetProcAddress(BassHandle, '_');
        if (BassFuncs = nil) then
        begin
          FreeLibrary(BassHandle);
          BassHandle := 0;

          MessageBox(0, 'Unable to load add-on functions from ''bass.dll''' + #13#10 + 'Halting the library process', 
         'Fatal Error!!', MB_ICONERROR);
          ExitCode := 1;
          Exit;
        end;
        System.IsMultiThread := true;
      end;
      DLL_PROCESS_DETACH:
      begin
        if (BassHandle <> 0) then
        begin
          FreeLibrary(BassHandle);
          BassHandle := 0;
        end;

        if (FindPluginsPtr <> nil) then
          StrDispose(FindPluginsPtr);
      end;
    end;
  end;

gruss Emil

[Klomeister]

IsMultiThread wird auf true gesetzt, um anzugeben, dass der Speichermanager mehrere Threads unterstützen soll. IsMultiThread wird von BeginThread und Klassengeneratoren auf true gesetzt

[EWeiss]

Zitat:

Zitat von Klomeister

IsMultiThread wird auf true gesetzt, um anzugeben, dass der Speichermanager mehrere Threads unterstützen soll. IsMultiThread wird von BeginThread und Klassengeneratoren auf true gesetzt

Das bedeutet ?
Es dürften dann eigentlich keine kompatibilitätsprobleme mit bsp.. Delphi 7
oder anderen sprachen mehr auftreten und das Debuggen würde fehlerfrei funktionieren?

Sorry ! Habe mich damit noch nicht richtig beschäftig.

Wie kann ein solches problem noch auftreten ?
obwohl die DLL Fehlerfrei läuft bei mir unter D06 auch beim debuggen
hat der user mit D7 immer abstürze sobald er debuggen will.

Ohne Debuggen funktioniert es einwandfrei!

Zitat:

I'll convince him to add exclusion to madCodeHook.

My will is to fix Bass_Vis.dll becouse it gives me a headache not using Delphi's built in debug mode, if it is needed give me the source code for Bass_Vis and I try to fix it. Or fix it somehow!

My problem is that I can't debug any projects under Delphi 7 (not even Turbo Delphi Explorer) when Bass_Vis.dll is loaded in the process space.

MP3 Stream Editor of course uses natively Filesystem Dialogs, and not hooked. Why should I hook when I load it with LoadLibrary()?

It's really indifferent weather a wrapper .dll is issuing LoadLibrary() or the main executable or whatever, as they are running in the same process space as of NT, as WindowsXP is a multiple - single process space architecture, not as Windows 98 where bunch of the .dlls are shared by all the processes, and a .dll failure can bring down the whole system.

Filesystem Dialogs's sources are totally freely available from the site.

I know that it works 100% without debugging, it works perfectly really, the only problem is when trying to debug an application with Bass_Vis.dll loaded, with my operating system, as you wrote it, that it works ok there.

My only aim is to fix the bug that makes problems here, and that means that it can give problems to other peoples too.

BassVis ist kein opensource und wird auch keiner daher habe ich nun das problem den Fehler so zu finden.

gruss Emil

[EWeiss]

Kann mein problem nicht lösen!
Hat jemand eine Idee warum manchmal beim debuggen unter Delphi 7 AVS auftreten und unter D06 nicht ?

Weiss mir da keinen rat mehr.

gruss Emil

[SirThornberry]

kommen die AV's beim Debuggen auch bei dir wenn du mit D7 debuggst oder nur beim Kunden?
Gründe für AV's können Dingen in den Watches etc. sein die Funktionen aufrufen oder anderweitig den Speicher verändern.

[EWeiss]

Zitat:

Zitat von SirThornberry

kommen die AV's beim Debuggen auch bei dir wenn du mit D7 debuggst oder nur beim Kunden?
Gründe für AV's können Dingen in den Watches etc. sein die Funktionen aufrufen oder anderweitig den Speicher verändern.

Bisher bei allen die D7 verwenden..
Habe es gerade mal installiert und will schauen ob es bei mir auch auftritt.
Ist aber schon seltsam keine probs in d06 und d7 macht ärger.

Fertige Anwendungen laufen ohne probleme nur debuggen kann man nicht.

gruss Emil

[SirThornberry]

würde ich dir auch empfehlen, dann siehst du auch an welchen Stellen die AV in der DLL kommt und kannst schauen an welcher Stelle im Source das ist.

[EWeiss]

Zitat:

Zitat von SirThornberry

würde ich dir auch empfehlen, dann siehst du auch an welchen Stellen die AV in der DLL kommt und kannst schauen an welcher Stelle im Source das ist.

Jo ..
Vielleicht ne dumme frage ;)
Hat IsMultiThread irgendeinen einfluss darauf ?
ob es sich nun debuggen läßt oder nicht ?

bzw.. sollte ich die AVS unterdrücken in der procedure wo das problem auftaucht ?

Saved8087CW := Default8087CW;
Set8087CW($133f);

gruss Emil

[SirThornberry]

Ob isMultiThread einen Einfluss darauf hat weiß ich nicht, sollte aber nicht wenn es in einem extra Modul steckt.
Und Fehler unterdrücken ist der falsche Ansatz. Eine Zugriffsverletzung kommt schließlich weil an einer falschen Speicheradresse auf Speicher zugegriffen werden soll. Im Schlimmsten fall kommt also mal keine Zugriffsverletzung und Speicher wird an falschen Stellen gelesen oder geschrieben. Es gilt also - Fehler finden!

[EWeiss]

Zitat:

Zitat von SirThornberry

Ob isMultiThread einen Einfluss darauf hat weiß ich nicht, sollte aber nicht wenn es in einem extra Modul steckt.
Und Fehler unterdrücken ist der falsche Ansatz. Eine Zugriffsverletzung kommt schließlich weil an einer falschen Speicheradresse auf Speicher zugegriffen werden soll. Im Schlimmsten fall kommt also mal keine Zugriffsverletzung und Speicher wird an falschen Stellen gelesen oder geschrieben. Es gilt also - Fehler finden!

Jo ist wohl der sinnvollste weg..
Nur konnte bisher keinen finden bei mir läuft das durch ohne zicken.
Vielleicht die compileroption zu stark eingestellt bei den anderen...

Hmm versteh das nicht!

Das wäre vielleicht mein ansatz gewesen.

Delphi-Quellcode:

  procedure LibraryProc(Reason: integer);
  begin
    case (Reason) of
      DLL_PROCESS_ATTACH:
      begin
        BassHandle := LoadLibrary('bass.dll');
        if (BassHandle = 0) then
        begin
          MessageBox(0, 'Unable to load ''bass.dll''' + #13#10 + 'Halting the library process', 'Fatal Error!!', MB_ICONERROR);
          ExitCode := 1;
          Exit;
        end;

        BassFuncs := GetProcAddress(BassHandle, '_');
        if (BassFuncs = nil) then
        begin
          FreeLibrary(BassHandle);
          BassHandle := 0;

          MessageBox(0, 'Unable to load add-on functions from ''bass.dll''' + #13#10 + 'Halting the library process', 'Fatal Error!!', MB_ICONERROR);
          ExitCode := 1;
          Exit;
        end;
        System.IsMultiThread := true;
        Saved8087CW := Default8087CW;
        Set8087CW($133f);
      end;
      DLL_PROCESS_DETACH:
      begin
        if (BassHandle <> 0) then
        begin
          FreeLibrary(BassHandle);
          BassHandle := 0;
        end;

        if (FindPluginsPtr <> nil) then
          StrDispose(FindPluginsPtr);

        Set8087CW(Saved8087CW)
      end;
    end;
  end;

um den Fehler der meistens hier auftritt wie berichtet zu umgehen..

Delphi-Quellcode:

function BASS_VIS_FindPlugins(vispath: PChar; flags: DWORD): PChar; stdcall;
var
  fPath: PChar;
  i, z: Integer;
  Plugins: String;
  DllHandle: THandle;
  VisList: TStringList;
  sSonique, sWinamp, fRecursive: Boolean;

  procedure SearchDir(const dPath: String);
  var
    x: Integer;
    sRec: TSearchRec;
  begin
    if (sSonique) then
    begin
      x := FindFirst(dPath + '*.svp', faAnyFile, sRec);
      while (x = 0) do
      begin
        if (FileExists(dPath + sRec.Name)) then
          VisList.Add(dPath + sRec.Name);

        x := FindNext(sRec); .....

Nur wie gesagt bei mir tritt keiner auf.
Auch unter D7 nicht.

gruss Emil

[EWeiss]

ich versuchs nochmal
Mein problem BassVis läßt sich in der environment von D7 aus der dort erstellten EXE nicht debuggen bei anderen usern.
Bei mir funktioniert es seltsamer weise ohne probleme.

Was könnte dieses Problem verursachen.
Habe es schon mit System.IsMultiThread versucht da der Thread in BassVis mit Create und nicht mit Begin
erstellt wird.

Jemand noch ideen ?

Würd mich mal interessieren ob das bei euch auch der fall ist.
Hier das Archiv..

2 Delphi projekte .. Sonique und Winamp.
Es geht also um D7 nicht um Do6

Delphi-Quellcode:

procedure TfrmMain.GetPlugin;
var
  IntI : integer;

begin

  // clear plugin list
  PluginList.Clear;

  // create temp list for new list of vis
  flist := TStringList.Create;

  // find out vis plugins
  flist.CommaText := BASS_VIS_FindPlugins(PChar(PluginDir),
                                          BASS_VIS_FIND_WINAMP or
                                          BASS_VIS_FIND_RECURSIVE or
                                          BASS_VIS_FIND_COMMALIST);

Hier einen breakpoint setzen flist.CommaText :=
Dort soll angeblich der AV immer auftreten.

gruss Emil

[OldGrumpy]

Riecht für mich nach Problemen mit dem Memory Manager... Ich hab leider kein Delphi 7, sonst würd ich da mal reinschauen. Am Breakpoint in die CPU-Ansicht umschalten und dort drin dann Opcode für Opcode vorwärts, dann sollte klarer werden, was da passiert. So aus der Ferne ist das aber auch nur Spekulation. Wäre z.B. hilfreich wenn man den ganzen Meldungstext der AV hätte :)

[EWeiss]

Zitat:

Zitat von OldGrumpy

Riecht für mich nach Problemen mit dem Memory Manager... Ich hab leider kein Delphi 7, sonst würd ich da mal reinschauen. Am Breakpoint in die CPU-Ansicht umschalten und dort drin dann Opcode für Opcode vorwärts, dann sollte klarer werden, was da passiert. So aus der Ferne ist das aber auch nur Spekulation. Wäre z.B. hilfreich wenn man den ganzen Meldungstext der AV hätte :)

Hier .. aber so richtig was mit anfangen kann man auch nicht.
Da die Hintergrundinfos fehlen.
Einzigste was ich weiss das er den genannten Breakpoint gesetzt hat und dort der
Fehler dann auftritt.

Was ich noch weiss er benutzt 'madCodeHook'
ka was das ist .. hab mich nicht mit beschäftigt.

gruss Emil

[EWeiss]

Ich habe folgenden Fehler festgestellt.

In einer meiner Units befand sich unter implementation eine nicht mehr vorhandene eingebundene Unit.
Aufgefallen ist mir das nachdem ich versucht habe meine DLL unter D7 zu kompilieren.

Seltsamerweise hat D06 hier keinerlei Probleme gemeldet und trotzdem die DLL kompiliert.
Denke mal das irgendwo im System (Suchpfad von D06) projekten diese Unit von D06 noch gefunden
wurde und deshalb keine fehlermeldung kam.

Kann es unterumständen daran liegen das D7 diesen Fehler beim debuggen meldet?
Weil eine nicht vorhande UNIT in die kompilierte DLL mit eingebunden wurde ?

Sehr seltsam das ganze.

gruss Emil

[SirThornberry]

ist BASS_VIS_FindPlugins eine Funktion der DLL und gibt einen String zurück?

[EWeiss]

Zitat:

Zitat von SirThornberry

ist BASS_VIS_FindPlugins eine Funktion der DLL und gibt einen String zurück?

Delphi-Quellcode:

 // find out vis plugins 
  flist.CommaText := BASS_VIS_FindPlugins(PChar(PluginDir), 
                                          BASS_VIS_FIND_WINAMP or 
                                          BASS_VIS_FIND_RECURSIVE or 
                                          BASS_VIS_FIND_COMMALIST);

Ja.
Array string ',' als Delemiter deshalb flist.CommaText.

EDIT:
Aus der DLL

Delphi-Quellcode:

function BASS_VIS_FindPlugins(vispath: PChar; flags: DWORD): PChar; stdcall;

export

BASS_VIS_FindPlugins ' Delphi
BASS_VIS_FindPlugins name 'BASS_VIS_FindPlugins@8'; 'MSVC


gruss Emil

[SirThornberry]

d.h du arbeitest mit ShareMem? Nicht das in D2006 ShareMem incompatibel zu ShareMem von D7 geworden ist oder sich die Strings intern irgendwie geändert haben.
Du könntest versuchen ob der Fehler bei den Kunden auch kommt wenn du die DLL mit Delphi7 kompilierst. Oder ist das schon der Fall?

[EWeiss]

Zitat:

Zitat von SirThornberry

d.h du arbeitest mit ShareMem? Nicht das in D2006 ShareMem incompatibel zu ShareMem von D7 geworden ist oder sich die Strings intern irgendwie geändert haben.
Du könntest versuchen ob der Fehler bei den Kunden auch kommt wenn du die DLL mit Delphi7 kompilierst. Oder ist das schon der Fall?

habe oben nochmal editiert.

Nein eigentlich nicht.
Die Funktion befindet sich direkt in der *.dpr vielleicht verursacht dies das Problem
Kann ich mir aber eigentlich auch nicht vorstellen.

Delphi-Quellcode:

function BASS_VIS_FindPlugins(vispath: PChar; flags: DWORD): PChar; stdcall;
var
  fPath: PChar;
  i, z: Integer;
  Plugins: String;
  DllHandle: THandle;
  VisList: TStringList;
  sSonique, sWinamp, fRecursive: Boolean;

  procedure SearchDir(const dPath: String);
  var
    x: Integer;
    sRec: TSearchRec;
  begin
    if (sSonique) then
    begin
      x := FindFirst(dPath + '*.svp', faAnyFile, sRec);
      while (x = 0) do
      begin
        if (FileExists(dPath + sRec.Name)) then
          VisList.Add(dPath + sRec.Name);

        x := FindNext(sRec);
      end;
      FindClose(sRec);
      (* <-- START --> UltraPlayer vis *)
      x := FindFirst(dPath + '*.uvs', faAnyFile, sRec);
      while (x = 0) do
      begin
        if (FileExists(dPath + sRec.Name)) then
          VisList.Add(dPath + sRec.Name);

        x := FindNext(sRec);
      end;
      FindClose(sRec);
      (* <-- END --> UltraPlayer vis *)
    end
    else if (sWinamp) then
    if BassVisInit then
    begin
      x := FindFirst(dPath + '*.dll', faAnyFile, sRec);
      while (x = 0) do
      begin
        if (FileExists(dPath + sRec.Name)) then
          VisList.Add(dPath + sRec.Name);

        x := FindNext(sRec);
      end;
      FindClose(sRec);
    end else
     begin
       BassFuncs^.SetError(BASS_ERROR_INIT);
       exit;
    end;

    if (fRecursive) then
    begin
      x := FindFirst(dPath + '*.*', faAnyFile, sRec);
      while (x = 0) do
      begin
        if (sRec.Name <> '.') and (sRec.Name <> '..') and (DirectoryExists(dPath + sRec.Name)) then
          SearchDir(dPath + sRec.Name + '\');

        x := FindNext(sRec);
      end;
      FindClose(sRec);
    end;
  end;
begin
  Result := nil;

  if (((flags and BASS_VIS_FIND_SONIQUE) <> BASS_VIS_FIND_SONIQUE) and ((flags and BASS_VIS_FIND_WINAMP) <> BASS_VIS_FIND_WINAMP)) or
     (((flags and BASS_VIS_FIND_SONIQUE) = BASS_VIS_FIND_SONIQUE) and ((flags and BASS_VIS_FIND_WINAMP) = BASS_VIS_FIND_WINAMP)) then
  begin
    BassFuncs^.SetError(BASS_ERROR_ILLPARAM);
    Exit;
  end;

  if (FindPluginsPtr <> nil) then
    StrDispose(FindPluginsPtr);

  VisList := TStringList.Create;

  sSonique := ((flags and BASS_VIS_FIND_SONIQUE) = BASS_VIS_FIND_SONIQUE);
  sWinamp := ((flags and BASS_VIS_FIND_WINAMP) = BASS_VIS_FIND_WINAMP);
  fRecursive := ((flags and BASS_VIS_FIND_RECURSIVE) = BASS_VIS_FIND_RECURSIVE);

  fPath := StrAlloc(Length(StrPas(vispath)) + 2);
  StrCopy(fPath, vispath);
  if (fPath[Length(StrPas(fPath)) - 1] <> '\') then
    StrCat(fPath, '\');

  SearchDir(StrPas(fPath));

  StrDispose(fPath);

  if (VisList.Count = 0) then
  begin
    VisList.Free;

    BassFuncs^.SetError(BASS_OK);
    Exit;
  end;

  for i := VisList.Count - 1 downto 0 do
  begin
    SetCurrentDirectory(PChar(ExtractFileDir(VisList[i])+ #0));
    DllHandle := LoadLibrary(PChar(VisList[i]+ #0));

    if (DllHandle <> 0) then
    begin
      if (sSonique) and (GetProcAddress(DllHandle, 'QueryModule') = nil) then
        VisList.Delete(i)
      else if (sWinamp) and (GetProcAddress(DllHandle, 'winampVisGetHeader') = nil) then
        VisList.Delete(i);
    end
    else
      VisList.Delete(i);

    FreeLibrary(DllHandle);
  end;

  if ((flags and BASS_VIS_FIND_COMMALIST) = BASS_VIS_FIND_COMMALIST) then
  begin
    FindPluginsPtr := StrAlloc(Length(VisList.CommaText) + 1);
    StrPCopy(FindPluginsPtr, VisList.CommaText);
  end
  else
  begin
    z := 0;
    Plugins := '';

    for i := 0 to VisList.Count - 1 do
    begin
      z := z + Length(VisList[i]) + 1;
      Plugins := Plugins + VisList[i] + #0;
    end;
    Plugins := Plugins + #0;

    FindPluginsPtr := StrAlloc(z + 1);
    CopyMemory(FindPluginsPtr, PChar(Plugins), z + 1);
  end;

  VisList.Free;

  BassFuncs^.SetError(BASS_OK);
  Result := FindPluginsPtr;

end;

Zitat:

Du könntest versuchen ob der Fehler bei den Kunden auch kommt wenn du die DLL mit Delphi7 kompilierst. Oder ist das schon der Fall?[/

habs noch nicht getestet wäre aber eine möglichkeit das mal zu probieren.

Gruss Emil

[EWeiss]

Dll in D7 ist kleiner als die von D06 verstehe wer will.
Ganze 3Kbit

Gruss Emil

[OldGrumpy]

Wenn ich das richtig verstehe, ist ShareMem ja fuer PCHAR gar nicht notwendig sondern nur für die Stringtypen von Borland selber - ich hatte auch erst in die Richtung gedacht, sah dann aber das PCHAR. Wenn man in Delphi ein DLL-Projekt anlegt, stehen im vorgefertigten Kram entsprechende Kommentare...

Was das "habs zufällig bemerkt als ich die DLL nochmal kompilierte" angeht: Genau aus dem Grund hab ich mir zur Angewohnheit gemacht, mehrteilige Projekte immer in einer Projektgruppe zu halten und entsprechende Projektabhängigkeiten zu definieren. Die Zeit die man ggf. mehr fürs Kompilieren braucht, ist bei der Fehlersuche schnell wieder eingespart :)

[EWeiss]

Zitat:

Zitat von OldGrumpy

Was das "habs zufällig bemerkt als ich die DLL nochmal kompilierte" angeht: Genau aus dem Grund hab ich mir zur Angewohnheit gemacht, mehrteilige Projekte immer in einer Projektgruppe zu halten und entsprechende Projektabhängigkeiten zu definieren. Die Zeit die man ggf. mehr fürs Kompilieren braucht, ist bei der Fehlersuche schnell wieder eingespart :)

ja stimmt schon ;)
aber seltsam doch das D7 das bemerkt und D06 irgendwas mit ins projekt compiliert
was nicht mehr vorhanden ist. (eigentlich)

Denke liegt wohl daran das D7 nicht in anderen außer den Projekt Ordner sucht.

Muss mal abwarten was die jetzt zu der neu compilierten DLL unter D7 sagen.
Ob es dann geht.

gruss Emil