XE7 raucht ab

[mm1256]

Hallo,

bevor ich mich an den EMBA-Support wende, möchte ich mal hier nachfragen. Ich habe seit einigen Wochen ein Problem mit XE-7 und kann mir nicht erklären, was die Ursache sein könnte. Das Problem ist einfach und auch permanent nachvollziehbar:

- ein vorhandenes Projekt öffnen, oder ein neues Projekt erstellen
- compilieren und einmal aus der IDE heraus starten

Wenn ich dann über "Datei => Öffnen" versuche eine Datei zu öffnen, wird die IDE geschlossen. Ohne Fehlermeldung, ohne Warnung, einfach nichts. Solange ich keine Datei öffne, kann ich problemlos stundenlang arbeiten. Auch wenn ich nicht compiliere, kann ich beliebige Dateien/Projekte öffnen. Das Problem tritt erst auf, nachdem ich einmal ein Projekt compiliere.

Hat jemand sowas schon gehabt, und wenn ja, was war die Ursache? Bzw. welche Möglichkeiten gibt es, der Ursache auf den Grund zu gehen?

[Mavarik]

Eigene Komponenten installiert?

Mavarik

[mm1256]

Zitat:

Zitat von Mavarik (Beitrag 1292584)

Eigene Komponenten installiert?

Ja, es sind aber in den letzten Wochen keine Neuen dazu gekommen.

[himitsu]

Zitat:

Zitat von mm1256 (Beitrag 1292583)

Bzw. welche Möglichkeiten gibt es, der Ursache auf den Grund zu gehen?

Genauso, wie immer jeden Tag. *narf*
Debuggen


IDE nochmal starten, dort "Start > Mit Prozess verbinden..." und eine Debugsession mit der ersten IDE-Instanz beginnen.
Nun in der anderen/ersten IDE arbeiten und warten bis es knallt.

[Mavarik]

Zitat:

Zitat von mm1256 (Beitrag 1292587)

Zitat:

Zitat von Mavarik (Beitrag 1292584)

Eigene Komponenten installiert?

Ja, es sind aber in den letzten Wochen keine Neuen dazu gekommen.

hmm... Also abgesehen vom MemoryLeak ist nach meiner Meinung XE7 die stabilste IDE seit langem.
Du bekommst die IDE "nur" down mit IDE Erweiterungen und eigenen Komponenten...

Ich würde beides mal nach und nach ausschließen.

Mavarik

Blöder roter Kasten...

Zitat:

Zitat von himitsu (Beitrag 1292588)

IDE nochmal starten, dort "Start > Mit Prozess verbinden..." und eine Debugsession mit der ersten IDE-Instanz beginnen.
Nun in der anderen/ersten IDE arbeiten und warten bis es knallt.

Klar so kann man die Stelle auch finden...

[ergeka]

Ich hatte ein ähnliches Verhalten mit XE6.
Die Ursache waren eigene DLLs, welche ich in das 'bin' Verzeichnis von Delphi kopiert hatte. Nachdem ich die wieder entfernt hatte, war alles wieder OK.

Es gibt auch einen QC Eintrag dazu:
http://qc.embarcadero.com/wc/qcmain.aspx?d=124919

Gruß

Ralf

[mm1256]

Dass die XE-7 IDE eine der stabilsten ist die es jemals gegeben hat, kann ich nur bestätigen. Darum bin ich ja auch so ratlos. Die ersten Monate nach der Installation letztes Jahr lief auch alles problemlos.

IDE-Erweiterungen habe ich nicht installiert. Die beiden Packages mit meinen eigenen Komponenten habe ich soeben mal testweise deaktiviert. Keine Änderung.

[mensch72]

mal das probiert?

http://www.delphipraxis.net/184179-b...ml#post1292441

[mm1256]

Zitat:

Zitat von ergeka (Beitrag 1292590)

Ich hatte ein ähnliches Verhalten mit XE6.
Die Ursache waren eigene DLLs, welche ich in das 'bin' Verzeichnis von Delphi kopiert hatte. Nachdem ich die wieder entfernt hatte, war alles wieder OK.

Es gibt auch einen QC Eintrag dazu:
http://qc.embarcadero.com/wc/qcmain.aspx?d=124919

Gruß

Ralf

oooops...vielen Dank für den Tipp. Das war's. FastMM_FullDebugMode.dll und FastMM_FullDebugMode64.dll entfernt und aktuell kein Problem mehr.

Komisch ist nur, dass FastMM nur in einem einzigen Projekt von mir verwendet wird. Also nicht in den Projekten verwendet wird, mit denen das Problem aufgetreten ist. Wie schon angemerkt, nachvollziehbar auch bei einem neu erstellten Projekt.

Irgendwie verstehe ich jetzt den Zusammenhang nicht :oops:

[Uwe Raabe]

Zitat:

Zitat von mm1256 (Beitrag 1292595)

Irgendwie verstehe ich jetzt den Zusammenhang nicht :oops:

Das ist offenbar ein Teil des Kopierschutzes von Delphi - wobei der geistige Zustand des Erfinders dieses Parts wohl eher als fraglich einzustufen ist.

[mm1256]

Danke Uwe für den sicher gut gemeinten Hinweis. Aber, wie hängt das mit dem Kopierschutz zusammen? Ich verstehe nur Bahnhof :cyclops:

[himitsu]

Der Kopierschutz reagiert ein bissl (über)empfindlich.

[Union]

Sobald Du Änderungen im /bin Verzeichnis vornimmst, wird Piratentum vermutet. Kein Parlay... ARRRHHH.

[Der schöne Günther]

Nicht nur dann.
Ich habe am bin-Verzeichnis nichts gedreht und alle paar Wochen gibt es so Tage da kann ich den ganzen Tag A Pirate I was meant to be, trim the sails and roam the sea! summen.

[mm1256]

Also nur, damit ich es richtig verstehe: Wenn ich die beiden DLL's in das Bin-Verzeichnis kopiere, meint EMBA ich sei ein Raubkopierer und raucht mir als Folge davon die IDE ab? Wenn dem wirklich so ist, wie zum Henker soll ich FastMM4 benutzen können? Dann müsste ich die DLL's in einem anderen Ordner "unterbringen" und den Suchpfad (wie??) erweitern?

Ich weiß, viele Fragen, aber, ich kann doch auch nicht der Einzige sein, der dieses Problem hat. Vielleicht stell ich mich ja auch zu dumm an, das mag auch sein :?:

[Der schöne Günther]

Ich dachte zuerst auch da wären sie gut untergebracht aber dann gab ich mein Piratenleben auf und legte sie in system32:

Code:

X:\>where fastmm*
C:\Windows\System32\FastMM_FullDebugMode.dll
C:\Windows\System32\FastMM_FullDebugMode64.dll

ARRRRRRR

[mquadrat]

Zitat:

Zitat von Uwe Raabe (Beitrag 1292597)

Zitat:

Zitat von mm1256 (Beitrag 1292595)

Irgendwie verstehe ich jetzt den Zusammenhang nicht :oops:

Das ist offenbar ein Teil des Kopierschutzes von Delphi - wobei der geistige Zustand des Erfinders dieses Parts wohl eher als fraglich einzustufen ist.

Vielleicht ein sehr brachialer Versucht DLL Injection zu vermeiden

[mm1256]

Zitat:

Zitat von Der schöne Günther (Beitrag 1292611)

Ich dachte zuerst auch da wären sie gut untergebracht aber dann gab ich mein Piratenleben auf und legte sie in system32

Auf den Trichter wäre ich auch gekommen, nur funzt das bei mir nicht (Win 8.1 64 Bit)

[edit]
sorry... C:\Windows\SysWOW64\ funzt

Vielen Dank für eure Hilfe!

[p80286]

Hab ich da was falsch verstanden?
Bei mir (D7,2006,XE) liegt die FastMM_FullDebugMode.dll in dem Ausgabeverzeichnis in das die Echsen geschrieben werden.

Gruß
K-H

[mm1256]

Zitat:

Zitat von p80286 (Beitrag 1292617)

Bei mir (D7,2006,XE) liegt die FastMM_FullDebugMode.dll in dem Ausgabeverzeichnis in das die Echsen geschrieben werden.

Das geht natürlich auch, aber dann brauchst du für jedes Projekt eine eigene Instanz der dll. Ist das im Sinn des Erfinders?

[Der schöne Günther]

Braucht man das für das Deployment nicht sowieso?

[Union]

Ich hoffe nicht dass jemand eine Anwendung mit aktivierten FullDebugMode deployed :shock:

[EWeiss]

Zitat:

Zitat von Union (Beitrag 1292620)

Ich hoffe nicht dass jemand eine Anwendung mit aktivierten FullDebugMode deployed :shock:

Warum nicht?
Das ist doch gerade der Sinn von FullDebugMode.
Wie sollen sonst Log-Dateien fremder/Unbekannter Anwender sinnvoll übermittelt werden. (Beta-Version)

gruss

[Union]

Weil man die Memory Leaks durch Entwicklertests herausfindet und eliminiert? Ich geb doch keine Anwendung in den Test oder die Produktion, wenn ich nicht sicher bin ob da Memory Leaks auftreten.

[mm1256]

Na ja, Fremden/Unbekannten würde ich niemals eine Debug-Version anvertrauen. Das mach ich nicht mal mit sehr guten Kunden, auch nicht mit Beta-Testern, und schon gar nicht wegen Logfiles zur Fehlersuche, weil jede Programmversion erst mal intern intensiv getestet wird. Aber da hat jeder wohl seine eigenen Ansichten und Vorstellungen.

[Der schöne Günther]

Oh ja. Sobald er kompiliert kann ausgeliefert werden. Der Rest kommt schon noch mit der Zeit. 8-)

[Sherlock]

Zitat:

Zitat von Union (Beitrag 1292622)

Weil man die Memory Leaks durch Entwicklertests herausfindet und eliminiert? Ich geb doch keine Anwendung in den Test oder die Produktion, wenn ich nicht sicher bin ob da Memory Leaks auftreten.

Von Embarcadero lernen, heisst siegen lernen....oder so.

Sherlock

[haentschman]

Zitat:

Von Embarcadero lernen, heisst siegen lernen....oder so.

...das verstehen eigentlich nur originale Ossis. :P Ich habe den Originalspruch auf einer roten Postkarte irgend wo im Archiv. :thumb: *Ostalgie*

[EWeiss]

Zitat:

Zitat von Der schöne Günther (Beitrag 1292626)

Oh ja. Sobald er kompiliert kann ausgeliefert werden. Der Rest kommt schon noch mit der Zeit. 8-)

JA, ja.
Siehe Spiele-Industrie was dabei rauskommt.

Nicht jedes System entspricht den Vorstellungen deiner Anwendung.
Also! Wie bitte willst du eine vernünftige LOG Datei bekommen ohne FullDebugMode.
Aber gut jeder wie er will.

Ich verwende FastMM in keiner meiner Anwendungen.

gruss

[hathor]

Zitat:

Zitat von haentschman (Beitrag 1292628)

Zitat:

Von Embarcadero lernen, heisst siegen lernen....oder so.

...das verstehen eigentlich nur originale Ossis. :P Ich habe den Originalspruch auf einer roten Postkarte irgend wo im Archiv. :thumb: *Ostalgie*

"...das verstehen eigentlich nur originale Ossis".

Stimmt nicht!

[jaenicke]

Zitat:

Zitat von Mavarik (Beitrag 1292589)

Also abgesehen vom MemoryLeak ist nach meiner Meinung XE7 die stabilste IDE seit langem.

Die Memory Leaks sind gar nicht mehr so ein Problem. Es reicht schon, wenn ich in XE7 ein großes Projekt kompiliere, dann ist der Speicher schon voll und XE7 stürzt ab. ;-)
Hoffentlich hilft es erst einmal, wenn wie angekündigt der Schalter aktiviert wird, dass die IDE zukünftig mehr als 2 GiB RAM nutzen kann... ist zwar auch schnell wieder Schluss, aber immerhin.

[Der schöne Günther]

Ist das dieses eine "LAA"-Flag im PE-Header? Könnte man sich das nicht selbst setzen? Oder schlägt dann der Kopierschutz zu?

[Daniel]

Zitat:

Zitat von Der schöne Günther (Beitrag 1292636)

Oder schlägt dann der Kopierschutz zu?

Der wird wohl zuschlagen. Schlimmer noch: Die IDE ist (noch) nicht in allen Bereichen dafür vorbereitet. Allein das Flag zu setzen, wäre auch für EMBT nicht so schwer gewesen, aber es sind noch weitere Arbeiten nötig - einige davon wurden jetzt bereits im anstehenden Release umgesetzt. Aber eben noch nicht alle.

[mm1256]

Zitat:

Zitat von jaenicke (Beitrag 1292634)

Die Memory Leaks sind gar nicht mehr so ein Problem. Es reicht schon, wenn ich in XE7 ein großes Projekt kompiliere, dann ist der Speicher schon voll und XE7 stürzt ab. ;-) ....

So große Projekte??? Ich dachte immer - bzw. kann das nur nachvollziehen - beim Compilieren einer Projektgruppe. Da ist nach etwa 8-9 Projekten, je nach Größe, Schluss. Stört mich persönlich weniger, weil die größte Projektgruppe erledige ich halt dann auf zweimal (zusammen 17 Projektdateien).

[himitsu]

Es kommt tatsächlich noch vor, daß einige Codes

Delphi-Quellcode:

< 0

als ungültige Zeiger ansehn, oder wo im höchsten Bit von Zeigern/Adressen irgendwelche Zusatzinfos kodiert sind ... bei ab 2 GB ist solcher Code tötlich.
Pointer als Integer interpretiert, anstatt als UIntPtr (Cardinal) usw. :stupid:

[arnof]

Zitat:

Zitat von mm1256 (Beitrag 1292583)

Hallo,

bevor ich mich an den EMBA-Support wende, möchte ich mal hier nachfragen. Ich habe seit einigen Wochen ein Problem mit XE-7 und kann mir nicht erklären, was die Ursache sein könnte. Das Problem ist einfach und auch permanent nachvollziehbar:

- ein vorhandenes Projekt öffnen, oder ein neues Projekt erstellen
- compilieren und einmal aus der IDE heraus starten

Wenn ich dann über "Datei => Öffnen" versuche eine Datei zu öffnen, wird die IDE geschlossen. Ohne Fehlermeldung, ohne Warnung, einfach nichts. Solange ich keine Datei öffne, kann ich problemlos stundenlang arbeiten. Auch wenn ich nicht compiliere, kann ich beliebige Dateien/Projekte öffnen. Das Problem tritt erst auf, nachdem ich einmal ein Projekt compiliere.

Hat jemand sowas schon gehabt, und wenn ja, was war die Ursache? Bzw. welche Möglichkeiten gibt es, der Ursache auf den Grund zu gehen?

Dieses nette Feature hatte ich unter XE5! Einmal öffnen ging bei 2'ten Projekt war die IDe einfach weg so wie Du das beschreibst.

Bei XE5 hatte mir das IDE PlugIn von "Andy's page" geholfen, das hier auch im Forum zu finden ist.

http://andy.jgknet.de/blog/ide-tools/delphispeedup/

[Bernhard Geyer]

Zitat:

Zitat von mm1256 (Beitrag 1292642)

So große Projekte??? Ich dachte immer - bzw. kann das nur nachvollziehen - beim Compilieren einer Projektgruppe. Da ist nach etwa 8-9 Projekten, je nach Größe, Schluss. Stört mich persönlich weniger, weil die größte Projektgruppe erledige ich halt dann auf zweimal (zusammen 17 Projektdateien).

Das Problem mit mehrer größe Projektgruppen haben auch älter Delphi-Version. Hist ist bei uns nach ca. 20 Projekte bei D6 schluss.

[Whookie]

Zitat:

Zitat von Der schöne Günther (Beitrag 1292611)

Ich dachte zuerst auch da wären sie gut untergebracht aber dann gab ich mein Piratenleben auf und legte sie in system32:

Code:

X:\>where fastmm*
C:\Windows\System32\FastMM_FullDebugMode.dll
C:\Windows\System32\FastMM_FullDebugMode64.dll

Der Vollständigkeit halber: Unter 64 bit Windows gehört das so:

Code:

C:\Windows\SysWOW64\FastMM_FullDebugMode.dll
C:\Windows\System32\FastMM_FullDebugMode64.dll

So läuft das jedenfalls unter Win7/8/8.1 bei mir problemlos (XE7/XE8).. vor dem XE8.1 update habe ich momentan doch etwas Respekt..