Standalone Exe vs. IDE+F9

[ISMIRSCHLECHT]

Hallo,

hier gleich das nächste "Feature" von Delphi 10.
Ich habe ein Programm , welches zwecks Zusammenarbeit mit einer C - dll diverse Buffer reservieren muß.
Starte ich das Programm aus der IDE, u.a. um zu debuggen, knallts, die Bufferlänge liegt bei ca 2^64, klar daß es dann abstürzt.
Aber wer beschreibt mein Erstaunen, als ich zufällig die Exe standalone startete und alles fubnktionierte !
Natürlich habe ich sogleich eine Release-Ausgabe kompiliert und aus der IDE zu starten versucht - rumms, krach...
Ist das jemandem schon mal passiert ?
Ist das ein Bug oder ein Feature, muß man in den Tiefen der Projekteigenschaften das Häkchen "Debugger bitte richtig rechnen" anhaken ?


Gruss
ism :shock:

[hoika]

Hallo,

Zitat:

und alles fubnktionierte !

Definiere das mal genau.

Funktioniert das Programm komplett? Klappt also das Zusammenspiel mit der Dll?
Oder kommt bloss keine Fehlermeldung?


Ich denke, es gibt schon einen Unterschied zwischen
1. Starte Prozess separat (Exe ohne Debugger)
2. Starte Prozess als SubProzess mit Debugger-Einfluss.

[Der schöne Günther]

Interessant wäre auch ob das auch auftritt wenn du deine Anwendung aus der IDE heraus, aber ohne Debugger startest. Vielleicht liegt es an Dingen wie übergebenen Umgebungsvariablen?

[Michael II]

Hast du auch dies versucht: Projekt > Optionen > Delphi Compiler > MSIBuild extern auf TRUE gesetzt?

Und wenn du in der IDE "wie gewohnt" debuggen willst, möchtest du eventuell auch noch Delphi Compiler > Linken > Mit externen Debug Symbolen auf TRUE setzen.

[Bernhard Geyer]

Speicherfehler müssen nicht immer zu crashes führen.
Je nachdem wohin zufälligerweise etwas zeigt kracht es oder auch nicht.
Und es ist sehr wahrscheinlich bei dir das außerhalb der IDE zufälligerweise eine Speicherbereich überschrieben wird der (nicht gleich) andersweitig benutzt wird.

[ISMIRSCHLECHT]

Hallo,

also:
1. Das Programm macht alles richtig .
2. Wenn ich mit Shift-Ctrl-F9 sarte funktioniert es auch

Was das Programm macht wäre zu umständlich zu beschreiben, in typischer C-Manier (Manie) werden Bytefelder beschrieben.


ism

[Bernhard Geyer]

Jetzt sehe ich erst -> 2^64 Bufferlänge

Was ist das für ein Komisches Konstrukt?
Gibts schon 128 Bit Compiler?

Was wollte der C-Entwickler damit erreichen?

[hoika]

Hallo,
klammere doch erst mal den c-Ansprech-Code aus.
Versuch also, dass Programm erst mal so in der IDE zum Laufen zu bringen.

[ISMIRSCHLECHT]

Hallo,

natürlich läuft das Programm in der IDE, wenn ich den C-Ansprechcode auskommentiere.
Aber der soll ja in einer DLL die Arbeit machen.
Es geht um die WORM-DLL für die Swissbitt-TSE.

Code auszugswise :

Delphi-Quellcode:

Type TUnChar =   array of Byte;

     PUnChar = ^TUnchar;

Var 
  sernu : PUnChar ;

new(sernu);
setlength(sernu^ , 512) ; 
// vor dem Aufruf ist die Länge von sernu^  noch 512 
worm_info_tseSerialNumber(definer.WINF,
                          sernu  ,
                          serlen);

// NACH dem Aufrum ist die Länge des Feldes plötzlich Null

Es sieht also so aus, als ob diese Dussel-DLL meinen Delphispeicher freigibt, so daß ich ihn nicht mehr ansprechen kann.
Hoch lebe die intersprachliche Zusammenarbeit
ism

[Luckie]

Ich bin mir ziemlich sicher, es liegt nicht an der DLL. Denn ich glaube kaum, dass du der Erste bist, der sie benutzt. Der Fehler wäre bestimmt beim Testen und bei anderen Nutzern aufgefallen.

[hoika]

Hallo,
schau mal hier

https://support.gastro-mis.de/suppor...cs/36000013743

[ISMIRSCHLECHT]

HI,

jaaa, das geht.
Ich habs mir leicht verändert nachempfunden, und es fungzoniert im Debugger wie als EXE.
Ich ba aber dabei philisophische Bauchschmerzen:
1. Vorne steht ein Getmem, hinten aber kein Freemen. Trotzdem schgeint der Hauptspeicher nicht hochzulaufen. Hoffe ich...
2. Ich weiß doch vorher nicht, wie lang die Seriennummer sein wird. Also hab ich dieselbe schön groß vereinbart.
Na mal sehn
ism :-D

[ISMIRSCHLECHT]

Mahlzeit,

nachdem das Auslesen der Seriennummer funktioniert ( in IDE und Standalone) bastle ich nun wieder an der
Transaktionssignatur.

Delphi-Quellcode:

// Vereinbarung:
  procedure worm_transaction_response_signature
                         (const TRES:IntPtr;
                          SIGNA: Pointer ;
                          var siglen: UInt64 );
                          cdecl; external 'WormAPI.dll';

  
  Type  PPByte = ^PByte;
  Var   aktsig:PPByte;
        siglen:UInt64;

  getmem(aktsig, 512);
  worm_info_read(WINF);
  worm_transaction_response_signature
               (Respob,
                aktsig,
                SIGLEN);
  {
  hier ist SIGLEN, d.h. die Länge der Antwort wieder      
  idiotisch hoch, nache 2^64 
  }
  SetLength(bites, siglen);  // (1)

  for i:= 0 to SIGLEN-1 do
    bites[i]:= aktsig^[i];   // (2)

Wie gestern bei der Seriennummer: Standalone gehts, in der IDE knallts.
Starte ich in der IDE mit Shift+Ctrl+F9 gehts auch.
Klar, daß es bei (1) schon rumst, zu (2) kommt er dann gar nicht mehr.
Es ist zum Auswachsen...
ism

[ISMIRSCHLECHT]

E R L E D II G T ! ! !


Das Response-Objekt war nicht mehr gültig, ja dann...
ism :wink: