Bedingte Compilierung

[Michael II]

Hallo Delphi,

ich nutze beim Debuggen fastmm. Wenn ich in der IDE unter Build Configuration "Debug" auswähle, mein Projekt erzeuge und starte, dann werden zwar die DLLs geladen, MeinProgramm.exe jedoch nicht. [MeinProgramm.exe wird im Windows Task Manager als Hintergrundprozess angezeigt.] Wenn ich in der IDE den "Stop Button" drücke, dann erscheint eine Meldung ich müsse Berlin neu starten.

Source:

program MeinProgramm;

uses
{$IFDEF DEBUG}
fastmm4,
{$ENDIF }
..
..



Ohne bedingte Compilierung:

program MeinProgramm;

uses
fastmm4,
..
..

klappt es (sowohl mit Build Config. "Debug" wie auch mit "Release"). MeinProgramm.exe wird wie erwartet geladen.

Hat jemand eine Idee wie sowas passieren kann? Bei mir klappt dies erst seit dem Berlin Update 1 nicht mehr.


Besten Dank!

Gruss
Michael

[himitsu]

Ist in deinem Debug-Profil auch DEBUG "definiert"?
Nur weil das Profil sich DEBUG nennt, muß nicht das "zufällig" gleichnamige Symbol "definiert" sein.
Projektoptionen > Compiler > Bedingungen

[Michael II]

Hallo himitsu

besten Dank für deine Antwort. Ja, das Symbol DEBUG ist definiert.

Nebenbei: Bei mir sind die Symbole DEBUG und RELEASE immer definiert - genau dort wo du schreibst (Release zum Beispiel: Delphi Compiler > Bedingungen > Inherit > Value from Release configuration > RELEASE).

Bei den früheren Delphi Versionen hat es geklappt.

Ich sehe, dass (wie erwartet) der initialization Teil von fastmm4 durchlaufen wird, ob fastmm4 nun IN der Bedingung oder AUSSERHALB steht.

Also sowohl so

Variante1:

programm Jass;
uses
fastmm4,
{$IFDEF DEBUG}
{$ENDIF }

wie auch so

Variante2:
programm Jass;
uses
{$IFDEF DEBUG}
fastmm4,
{$ENDIF }

; das Symbol DEBUG ist also definiert [ich sehe dies auch an anderer Stelle im Programm].

Es steht also (bei definiertem Symbol DEBUG) zwei Mal das "Gleiche" da.

Wenn ich Variante 1 erzeuge, dann klappt alles wunderbar.
Wenn ich Variante 2 erzeuge [also den genau "gleichen" Quellcode verwende] und laufen lasse, dann bleibt das Ding in 100% aller Fälle hängen. Ich drücke in der IDE den Stop Button und es wird angezeigt "Debugger fatal error during process reset"; ich solle meine Arbeit speichern und Delphi neu starten.

Da bei beiden Varianten DEBUG definiert ist, sollte es ja mit Variante 2 klappen, wenn es mit Variante 1 funktioniert (?).

[Nebenbei: Variante 3 ohne die Verwendung von fastmm4 funktioniert.]


Ich bin froh um jeden Tipp. Danke.


Gruss aus Wabern (CH),
Michael

[Michael II]

Nur noch kurz... es handelt sich nicht um ein generelles Problem. Auch in anderen Programmen verwende ich fastmm4 (wie in meiner Meldung erwähnt) - und dort klappt es.

[himitsu]

Auf die Schnelle fällt mir nix ein, aber wozu brauchst du denn FastMM?
Wenn du keine besonderen Features davon verwendest (z.B. erweiterte Fehlerprüfungen oder so), dann ist es nicht nötig, da seit Delphi 2006 bereits eine "kleinere" Version des FastMM im Delphi enthalten ist.

[Dalai]

Ist das Leerzeichen vor der schließenden Klammer des {$ENDIF} Absicht oder ein Versehen? Unabhängig davon hoffe ich, dass dieses Leerzeichen in deinem Projekt nicht vorhanden ist, denn das gehört da nicht hin.

Grüße
Dalai

[himitsu]

Dieses Leerzeichen stört notfalls auch nicht. (bei einem Leerzeichen zwischen { und $ wäre es dagegen was Anderes)

[Michael II]

Danke himitsu und Dalai für Eure Antworten!

Danke Dalai für den Hinweis punkto Leerzeichen. Du fragst Absicht oder Versehen? Spock würde wohl mit Ja antworten .
Wie himitsu schreibt: Das Leerzeichen an dieser Stelle wird vom Compiler nicht beachtet. [Ich hab's aber trotzdem nun weggeputzt...]

Zu meinem Problem: Ich habe das Projekt nun in Seattle geladen und gestartet und dort klappt es.
Ich habe fastmm4 entfernt, aber nach einiger Zeit war das Problem auch ohne fastmm4 zurück: Wenn ich Start(F9) drücke, dann werden 59 Module geladen und dann ein weiteres geladen und gleich wieder entladen.
Leider sehe ich bei diesem Modul nicht, wie es heisst. Da scheint es irgend ein Pointer Problem zu geben; mal ist im Ereignisprotokoll der Modul Name leer, dann wird MZP angezeigt und dann wieder ������������������� [und viele andere Dinge]
:

So sieht es im Ereignisprotokoll aus:

Module Load: srvcli.dll. No Debug Info. Base Address: $6CFD0000. Process Jass.exe (12336)
Module Load: . No Debug Info. Base Address: $03710000. Process Jass.exe (12336)
Module Unload: . Process Jass.exe (12336)

oder so:
Modullade-Haltepunkt bei $65054A30: Modul srvcli.dll geladen. Prozess Jass.exe (10116)
Modul laden: MZP. Ohne Debug-Infos. Basisadresse: $03740000. Prozess Jass.exe (10116)
Modul entladen: MZP. Prozess Jass.exe (10116)

oder so:
Modul laden: srvcli.dll. Ohne Debug-Infos. Basisadresse: $65050000. Prozess Jass.exe (3144)
Modul laden: �������������������
 
!%368:<. Ohne Debug-Infos. Basisadresse: $05030000.
Prozess Jass.exe (3144)
Modul entladen: �������������������
 
!%368:<.


Wenn nach dem Start(F9) Delphi Berlin Update 1 hängt, dann wird in der Ereignisanzeige nur noch das Laden von srvcli.dll angezeigt. Danach muss Delphi jeweils neu gestartet werden.

Ich merke, dass ich hier punkto Wissen an meine Grenzen stosse... hat jemand einen Tipp, wie ich herausfinden kann, wie das Modul heisst, welches zu diesem Problem führt? Und wie ich das Laden verhindern kann? [Bei Seattle ist der Name des Moduls in der Ereignisanzeige immer leer. Wahrscheinlich klappt es deshalb dort immer.]



Besten Dank.

Gruss
Michael

[Dalai]

Überempfindlicher Virenscanner (vielleicht mit integrierter Sandbox)?

Grüße
Dalai

[Michael II]

Hallo dalai

danke für deinen Hinweis. Nun das compilierte Programm funktioniert ja [also wahrscheinlich kein Scanner Problem], einfach beim Debuggen schmiert die Sache immer wieder ab (Delphi schmiert ab [Fehlermeldung einsenden], oder Delphi läuft zwar noch meldet aber, ich müsse meine Arbeit speichern und Delphi neu starten oder es wird angezeigt Assertion failure:"!"UNKNOWN evaluator type "" in ..\win32src\DBKIMPL.CPP at line 4017).


Ich habe nun dank ProcMon auch gesehen, an welcher Stelle im Code ab und zu alles stehen bleibt: Beim Setzen einer .lnk Datei auf dem Desktop. Wieso es passiert, weiss ich allerdings nicht.

Da mein eigener Code etwas "aufgeblasen" ist, habe ich nach einem anderen gesucht, bei welchem das Problem auch auftritt und bei about gefunden (Code unten).

Wenn ich den Code unten lade, das Programm erzeuge, einen Haltepunkt in der Zeile
IPFile.Save(PWChar(LinkName), false) ;
setze und dann starte(F9), dann sehe ich, dass bei der Ausführung der obigen Zeile ein Modul geladen und wieder entladen wird. Mal ist der Name des Moduls leer (zum Beispiel immer bei Seattle) und mal wird irgend ein String angezeigt. Und ab und zu schmiert es wie eingangs erwähnt ab.

Auf meinem Rechner (Win10 Anni Update) passiert dies nur mit Delphi Berlin Update. Vielleicht hat ja ein delphipraxis Mensch einen Tipp, wie man es so macht, dass es auch mit DBUp klappt.



(* uses ShlObj, ActiveX, ComObj; *)

procedure lnk_auf_desktop;
var IObject : IUnknown;
ISLink : IShellLink;
IPFile : IPersistFile;
PIDL : PItemIDList;
InFolder : array[0..MAX_PATH] of Char;
TargetName : String;
LinkName : WideString;
begin
TargetName := Application.ExeName; {
Use TargetName:=ParamStr(0) which returns the path and file name of the
executing program to create a link to your Application}
IObject := CreateComObject(CLSID_ShellLink) ;
ISLink := IObject as IShellLink;
IPFile := IObject as IPersistFile;
with ISLink do
begin
SetPath(pChar(TargetName)) ;
SetWorkingDirectory(pChar(ExtractFilePath(TargetNa me))) ;
end; // if we want to place a link on the Desktop
SHGetSpecialFolderLocation(0, CSIDL_DESKTOPDIRECTORY, PIDL) ;
SHGetPathFromIDList(PIDL, InFolder) ;
{ or if we want a link to appear in
some other, not-so-special, folder:
InFolder := 'c:\SomeFolder' }
LinkName := InFolder + '\Delphi Created Link.lnk';
IPFile.Save(PWChar(LinkName), false) ;
end;

Quelle: http://delphi.about.com/od/windowssh...create_lnk.htm

Gruss
Michael