[Aspartam]

Hi,

seit ich auf MSVC .NET 2003 umgestellt habe, stürzen manche von mir erstellten Programme auf manchen Rechnern ab. Werden sie mit MSVC 6 SP6 übersetzt, gibt es keine Probleme.

Die Abstürze scheinen nur auf älteren Rechnern aufzutreten, und zwar z.B. bei so simplen Gelegenheiten wie einer impliziten Typwandlung Fließkomma -> Ganzzahl (also z.B. int i, r=1; i = r*2.4).

Ich habe keinerlei besondere Optimierungen (z.B. P4 oder SSE2/3) aktiviert, sondern nur allgemein "schnellsten Code erzeugen" eingeschaltet.

Wird die Software ganz ohne Optimierungen erstellt, gibt's keine Probleme.

Kann mir da jemand weiterhelfen?

[Witi]

In welcher .NET Framework Version haste die kompiliert?
Es könnte sein, dass auf den anderen PC ne andere installiert ist...

Haste mal versucht ne Exception abzufangen?
Wenn Programme ohne Grund abstürzen, geben sie in der Regel noch eine Exception aus...

[Aspartam]

.NET 1.1 + Hotfix.

Ich habe die RTL als multithreaded DLL gelinkt, das ändere ich aber.

Allerdings gab's einen Absturz wie gesagt bei einer simplen Wandlung double -> int.

[Witi]

Zitat (Aspartam: 11.03.2005, 14:16)

Allerdings gab's einen Absturz wie gesagt bei einer simplen Wandlung double -> int.
<{POST_SNAPBACK}>

Wie eben schon gefragt....Exception?

[Rika]

Was nun? MSVC6 übersetzt keine .NET-Sprachen, oder machst du die Managed- 'C++'-Grütze?

Indes, schon mal Optimierungen abgeschaltet? Debug-Version?

[Aspartam]

Witi - keine Ahnung, nicht abgefangen.

Rika - unkonstruktiv. Lesen.

[Rika]

Nein, sinnvolle Nachfrage.

Also, nochmal als Zusammenfassung: Du hast einige Programme, die du sowohl mit MSVS6-SP6 und MSVC.NET2003 kompilierst. Das schränkt die Programmiersprachen auf C und C++ ein, da MSVS6 weder C# noch VB.NET noch MSIL noch J# unterstützt, und VS.NET2003 wiederum kein VB6.

Dann fragt dich Witi, unter welchem .NET Framework du es kompiliert hast, und du antwortest positiv darauf. Von den beiden Sprachen C und C++ hat allenfalls C++ etwas mit .NET zu tun, nämlich bei Managed C++.

Also entweder programmierst du in C++ und kompilierst bei VS.NET2003 mit Managed Code for C++, dann sei dir dringend anzuraten auf letzteres zu verzichten und nur nativen Code zu erzeugen. Oder deine ganzen Aussagen passen nicht zusammen.

Ist es also so unverständlich, wenn ich da mal nachfrage?

Indes, auch die Empfehlung, mal Debug- statt Release-Code zu erzeugen oder wenigstens die Optimierungen abzuschalten, ist eine vernünftige Standardempfehlung

Und wie wär's mal, wenn du, wie von Witi empfohlen, einfach mal ein einfaches

try {
// dein Code
}
catch (Exception e) {
sprintf("%s",e);
}

hinklatschst und mal schaust was für Exceptions generiert werden?

Dieser Beitrag wurde von Rika bearbeitet: 11. März 2005 - 23:16

[Aspartam]

Ich habe im Leben noch nichts von Managed Dingenskirchen gehört.

Die Applikationen benötigen kein .NET Framework, es ist aber auf den Maschinen installiert.

Es sind z.T. MFC-Applikationen, z.T. Plain C (altes 3D-Spiel).

Seit ich die Sachen mit MSVC .NET 2003 compiliert habe, benötigen Sie z.T. eine msvcr71.dll, z.T. eine mfc71.dll (Linker-Option "multithreaded DLL"). Verwende ich als Linkeroption "multithreaded", gibt's übrigens sofort einen Absturz (auf jeder Maschine), den ich vorerst nicht weiter untersucht habe.

Mit MSVC 6 habe ich - aus welchen Gründen auch immer - keine derartigen Probleme.

Der "Fließkomma"-Absturz ereignet sich im 3D-Spiel auf einer einer Maschine eines Nutzers des Spiels, zu der ich keinen weiteren Zugang habe. Den Exception-Handler einzubauen bringt mich deshalb momentan gar nicht weiter.

Einen Absturz in der MFC-Applikation habe ich aus Zeitmangel gar nicht weiter verfolgt sondern bin auf MSVC 6 zurück, denn meine Kollegen wollten weiterarbeiten.

Dass es keine Abstürze gibt, wenn es keine Code-Optimierung gibt, hatte ich schon geschrieben.

Wenn ich die Software mit MSVC .NET 2003 ohne Optimierungen übersetze, gibt es den Fließkomma-Absturz nicht mehr, soweit ich mich erinnere aber immer noch den Absturz in der MFC-Applikation. Diese stürzt auf einem Athlon XP 1800+ mit Win2K pro (aktuellster Service Pack, NNET Framework 1.1 + Hotfix installiert) ab. Der Absturz ereignet sich auch, wenn ich msvcr71.dll in das Arbeitsverzeichnis des Programms stelle. Auf dieser Maschine läuft das 3D-Spiel jedoch wiederum tadellos.

Auf 64-Bit-Maschinen gibt es keine Abstürze - allerdings habe ich in den Optimierer-Optionen keine Code-Generierung für solche Prozessoren eingestellt, sondern Prozessortyp "blend" gewählt. Es sind auch keine globalen Optimierungen, weglassen des (Stack) Frame Pointers oder Erstellen von SSE2/SSE3-Code eingestellt, einfach nur "schnellster Code". Auch "intrinsic functions" ist *aus*.

Ich habe den Optimierer in Verdacht, kann aber nicht sagen, was dahinter steckt.

Da ich mittelfristig auf jeden Fall beruflich zum Umstieg auf MSVC .NET 2003 gezwungen bin, suche ich nun nach zweckdienlichen Hinweisen.

Dieser Beitrag wurde von Aspartam bearbeitet: 12. März 2005 - 16:33

[Rika]

Aha, hat also doch nix .NET zu tun. Also:

1. Versuch's mal mit MFC mit statischer Bindung.
2. Schalte mal die Optimierung für verbesserte Floating Point Precision ein.
3. Welchen Compiler verwendest du? Bei mir heißt "blend" einfach nur "none" und es ist bestenfalls SSE2-Code erstellbar. Du nimmst doch nicht etwa den ICC?
4. Die schlimmste aller Möglichkeiten: Dein Code ist einfach Shice. VC71 interpretiert den C/C++-Standard wesentlich strenger und genauer als der VC6. Schalte mal die Compiler-Warnings ein, auf maximaler Stufe (/W4).

Dieser Beitrag wurde von Rika bearbeitet: 12. März 2005 - 17:10

[Aspartam]

Ich wüßte nicht, was an

int i, j;

i = 10;
j = i*2.4;

so bescheiden programmiert sein sollte, daß deshalb das ganze Programm abstürzt.

Die Spielerei mit FP Precision hatte übrigens nichts gebracht, habe ich alles ausprobiert.

Wenn ich mit MSVC .NET 2003 statisch linke, stürzt das MFC-Programm sofort ab. Mit MSVC 6 nicht. Das werde ich aber noch hinkriegen, ist nur eine Zeitfrage.

Bei Prozessoroptimierungen gibt es bei mir nur "blended", "Pentium", "Pentium pro, II, III" und "Pentium IV and above".

Ich programmiere übrigens schon ziemlich lange und eigentlich gar nicht sch..., und mir gefallen solche Bemerkungen nicht.

Ich denke, ich kriege das alleine raus - wie immer. Dauert halt etwas länger.

Dieser Beitrag wurde von Aspartam bearbeitet: 13. März 2005 - 22:48

[Rika]

Zitat

Ich wüßte nicht, was an

int i, j;

i = 10;
j = i*2.4;

so bescheiden programmiert sein sollte, daß deshalb das ganze Programm abstürzt.

OK, dann stimmt definitiv was nicht. Chkdsk laufen lassen, MSVC neuinstallieren...

Zitat

Bei Prozessoroptimierungen gibt es bei mir nur "blended", "Pentium", "Pentium pro, II, III" und "Pentium IV and above".

Achso, das meinst du. Hat aber nix mit SSE/SSE2 zu tun.

Zitat

Ich programmiere übrigens schon ziemlich lange und eigentlich gar nicht sch..., und mir gefallen solche Bemerkungen nicht.

Lies mal "C Traps and Pitfalls" von Andrew Koenig, da lernen auch gestandene Programmierer nicht aus. Außerdem ist hinreichend bekannt daß MSVC6 sehr sehr lasch mit dem Code umgeht.

[Aspartam]

Denkst Du allen Ernstes, nach 20 Jahren Programmiererfahrung stolpere ich noch über Mißverständlichkeiten mit C/C++?

Willst Du mir erzählen, wenn der Optimierer irgendwo den Code verbeult, helfen chkdsk oder Neu-Inst. irgendwas?

Hehe, wenigstens bist Du mal lustig geworden.

Dieser Beitrag wurde von Aspartam bearbeitet: 14. März 2005 - 16:09

[Rika]

Zitat

Denkst Du allen Ernstes, nach 20 Jahren Programmiererfahrung stolpere ich noch über Mißverständlichkeiten mit C/C++?

Ja, ganz ehrlich. Insbesondere unklärbare Mißverständlichkeiten wie z.B. int r= -3 / 2.

Zitat

Willst Du mir erzählen, wenn der Optimierer irgendwo den Code verbeult, helfen chkdsk oder Neu-Inst. irgendwas?

Wenn du auch einem nichtkonsistenten Dateisystem kompilierst, brauchst du dich über gar nix zu wundern. Und MSVC.NET ist so komplex, daß ein kleiner Fehler das ganze Ding kaputtmacht - und wenn das Problem immer auftritt, dann würde ich davon ausgehen. Selber schon erlebt, Neuinstallation war alles andere als trivial.

[Aspartam]

Ich halte int r= -3 / 2; nicht für mißverständlich. Jedenfalls nicht mit MSVC.

Mein Dateisystem ist konsistent.

Ich sage Dir dann bei Gelegenheit, was es wirklich war.

Dieser Beitrag wurde von Aspartam bearbeitet: 15. März 2005 - 03:15