JLI Spieleprogrammierung Foren-Übersicht JLI Spieleprogrammierung

 
 FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen 
 medals.php?sid=730c6d577bd212cb49605cbe333b50bbMedaillen   RegistrierenRegistrieren   ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin 

[.Net 2.0 SP1][C#] Fehlerfrei in Debug, Absturz in Release

 
Neues Thema eröffnen   Neue Antwort erstellen    JLI Spieleprogrammierung Foren-Übersicht -> Entwicklung
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
Fetze
Mini JLI'ler



Anmeldedatum: 23.11.2008
Beiträge: 16

Medaillen: Keine

BeitragVerfasst am: 25.11.2008, 17:40    Titel: [.Net 2.0 SP1][C#] Fehlerfrei in Debug, Absturz in Release Antworten mit Zitat

Ich kann seit kurzer Zeit im Releasemodus keine fehlerfreien Anwendungen mehr kompilieren. Ich bastele an einem Modulkomplex mehrerer miteinander in Verbindung stehender Projekte, die aufeinander aufbauen und eine Art Referenzkette bilden. Ich weiß nicht, wieso, aber seit kurzem funktioniert das "Endprogramm" nur noch im Debugmodus, im Releasemodus erscheint die folgende Fehlermeldung:



Exakt der gleiche Code funktioniert einwandfrei wenn von Visual Studio aus gestartet, lässt das Programm aber mit unbehandelter Exception abstürzen, wenn ich es nach "Neu Erstellen" ohne Visual Studio starte.

Ich verwende keine COmpilerdirektiven, die mit dem Debug- oder Releasemodus in Verbindung stehen.

Der Fehler tritt in der folgenden Zeile auf (Habe das per Console-Logs nach und vor jeder Zeile getestet):
Code:

buffer = new byte[len];

Wobei buffer natürlich als byte[] deklariert ist und len einen normalen Wert (1207, um genau zu sein) hat.


Hilfe? :/



PS: Interessant ist auch, dass die .exe im Debugordner einzeln gestartet so schnell läuft, als wäre es eine Releasemode-exe... normalerweise gibt es - wenn ich das Projekt von Visual Studio aus starte - aber große Leistungseinbußen.. ôo
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Dr. Best
Senior JLI'ler


Alter: 33
Anmeldedatum: 17.06.2004
Beiträge: 269
Wohnort: Köln
Medaillen: Keine

BeitragVerfasst am: 25.11.2008, 18:26    Titel: Antworten mit Zitat

Genau kann ich es dir nicht sagen, aber es wird darauf hinauslaufen, dass du irgendwo undefiniertes Verhalten hast. Eine Zugriffsverletzung (lesen oder schreiben mit ungültigem Pointer) oder falsche delete-Aufrufe könnten die Ursache sein. Eine weitere Möglichkeit ist, dass du irgendwo Variablen nicht definierst bevor du daraus liest (so dass du willkürlichen Datenschrott darin hast, der dann später Probleme machen kann). Undefiniertes Verhalten ist eben durch den Programmcode allein nicht festgelegt. Es hängt von Faktoren wie momentanem RAM Inhalt und Speicherverwaltung ab und daher ist es nicht ungewöhnlich, dass es sich nur unter bestimmten Umständen bemerkbar macht.

Um es in solchen Fällen, wo es im Debugmodus nicht auftritt, besser analysieren zu können habe ich mir neulich noch einen kleinen Trick ausgedacht (der bei mir zumindest ein mal funktioniert hat). Ich habe einfach auf dem Stack ein völlig funktionsloses, aber ziemlich großes Array angelegt. So in der Art:
Code:
int DeleteMeAfterDebugging[100000];

Dadurch hat sich das undefinierte Verhalten dann auch im Debugmodus bemerkbar gemacht und ich konnte es problemlos beheben. Ist zwar ein bisschen bizarr, das sowas zum Ziel führt, aber wenn es klappt kann man zufrieden sein Very Happy .

P.S.: Fixier dich bloß nicht zu sehr auf diese Zeile, die du da jetzt als Endpunkt des Programms ausgemacht hast. Es ist sehr wahrscheinlich, dass vorher schon jede Menge schief geht und nur deshalb der new Aufruf dann nicht mehr klappt.
_________________

Ich bin da, wer noch?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen AIM-Name MSN Messenger
Fetze
Mini JLI'ler



Anmeldedatum: 23.11.2008
Beiträge: 16

Medaillen: Keine

BeitragVerfasst am: 26.11.2008, 09:28    Titel: Antworten mit Zitat

Falls ich das noch nicht gesagt habe, vllt hilft es weiter:
Wenn ich die betroffene .dll durch die der debuversion ersetze (und alle anderen Dateien so lasse wie sie sind), dann läuft das Programm insgesamt völlig fehlerfrei.

Bevor ich diesen Fehler hier hatte trat auch schon ein anderer in derselben Methode auf (recht nah an der jetzigen Zeile), beim Versuch, Assembly.GetExecutingAssembly() oder GetCallingAssembly() aufzurufen. Ich habe die jeweilige Zeile durch GetAssembly(Type t) ersetzt und es lief wieder einwandfrei. Shocked
Hier die vorherige Fehlermeldung:





Zu deinem Post:
Nun, Zugriffsverletzungen sind eher schwierig, wenn man keine Pointer und nur managed code verwendet.. was meinst du mit falschen delete-Aufrufen?

Sollte sich bei nicht definierten Variablen nicht schon VOR dem Kompilieren der Debugger melden? (In welchen Fällen nicht?)

Danke für deinen Tip, aber bei mir tut sich da nichts. :/
Ich habe ein Array mit "int[] debug = new int[zahl];" initialisiert, ein kleines Stück vor der Fehlerbehafteten Stelle, zu Beginn der jeweiligen Methode (ist etwas größer). Entweder passiert gar nichts, oder - wenn ich das Array immer größer mache - es tritt ein OutOfMemory- oder Overflow-Fehler bei dr Initialisierung des Debugarrays auf. Was aber nru verständlich ist und mich nicht weiterbringt :/

Vorschläge?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Dr. Best
Senior JLI'ler


Alter: 33
Anmeldedatum: 17.06.2004
Beiträge: 269
Wohnort: Köln
Medaillen: Keine

BeitragVerfasst am: 26.11.2008, 10:24    Titel: Antworten mit Zitat

Oi, Managed Code. Ich mag Garbage Control nicht, aber naja, kein off-topic. Mit dem Debuggen von Managed Code habe ich noch nicht viel Erfahrung, aber vielleicht kann ich dir ja trotzdem helfen.

Falsche delete-Aufrufe sind bei Managed Code natürlich nicht machbar. Aber dass du nirgendwo Pointer verwendest kommt mir leicht unglaubwürdig vor ^_^ . Du wirst ja wohl gelegentlich Heapspeicher nutzen, da kommst du ohne Pointer doch garnicht aus. Außerdem braucht man für Zugriffsverletzungen nicht zwangsläufig Pointer (zumindest nicht explizit). Array look-ups mit ungültigen Indizes können auch Zugriffsverletzungen verursachen. Mal ein Beispiel, bei dem auch noch uninitialisierte Variablen vorkommen. Ist zwar Unmanaged C++ Code und nicht schön, aber müsste trotzdem ganz gut übertragbar sein:
CPP:
int pBar[10000];

class CFoo{
public:
    CFoo(){
       // Some data, but not iBar is initialized here
    }
    CFoo(unsigned short iBarIn){
        iBar=iBarIn;
        // Some other data is also initialized here
    }

    int GetBar() const{
        return pBar[iBar];
    }

private:
    unsigned short iBar;
    // ...
};

CFoo Foo1;
CFoo Foo2(3);

Foo2.GetBar(); // The value of CFoo::iBar is 3, the function works
Foo1.GetBar(); // The value of CFoo::iBar is random, the behavior
// of the function is undefined. It can not be predicted.

Wird CFoo mit dem zweiten Konstruktor initialisiert hat CFoo::iBar einen ordentlichen Wert und GetBar() funktioniert. Wird aber der erste Konstruktor verwendet wird CFoo::iBar garnicht verändert. Dann enthält es den Datenschrott, der eben gerade im Speicher war. Das wäre dann in vielen Fällen so eine Zahl wie 0xcdcd, also irgendwas sehr großes und entsprechend würde CFoo::GetBar() eine Zugriffsverletzung verursachen. Der Wert von CFoo::iBar ist in diesem Fall aber eben undefiniert. Es kann auch sein, dass der Speicher an der Stelle gerade den Wert 1234 oder 0 enthält. In beiden Fällen würde GetBar() funktionieren. Das Verhalten des Programms ist undefiniert, es ist durch den Programmcode alleine nicht festgelegt. Deswegen kann es auch passieren, dass es im Releasemodus Probleme gibt und im Debugmodus nicht.

Ich weiß jetzt nicht ob Standarddatentypen sich bei Managed Code immer von selbst mit Standardwerten initialisieren. Wenn das der Fall ist, ist das Beispiel natürlich auch hinfällig. Aber bei Managed Code gibt es sicherlich auch Möglichkeiten undefiniertes Verhalten zu erhalten. Man muss es nur irgendwie hinkriegen dafür zu sorgen, dass an uninitialisierten Stellen im Speicher gelesen oder geschrieben wird (fast jedes undefinierte Verhalten ist in irgendeiner Weise darauf zurückzuführen). Nach so etwas musst du Ausschau halten.

Mit Fehlern wie Zugriffsverletzungen kann man unter Umständen so Dinge wie Heapcorruption bewirken. Dann kann es einfach bei jedem new-Aufruf passieren, dass eine Ausnahme auftritt obwohl der Aufruf ansich richtig war. Es ist wahrscheinlich, dass dein jetziger Fehler und der bei Assembly.GetExecutingAssembly() die gleiche Ursache haben.

Zu deiner Umsetzung meines Tipps. Du hast jetzt ja ein Heaparray benutzt (mit new erstellt). Wenn es das bei Managed C# gibt probier's nochmal mit einem Stack Array, also einem das ohne new erstellt ist. Und deklariere es nach Möglichkeit an einer Stelle im Code an der es vom Anfang der Programmausführung bis zum Ende bestehen bleibt. Habe noch keine langfristigen Erfahrungen mit diesem Trick, aber das eine mal wo ich ihn ausprobiert habe hat es eben funktioniert.

Und ansonsten halt schön alle Pointer, Referenzen und Array Indizes auf ihre Gültigkeit prüfen. Und gucken ob du irgendwelchen Funktionen Daten gibst, die sie nicht vertragen. Am besten dazu das Programm so weit wie möglich reduzieren, damit du einen kleineren Bereich durchsuchen musst.
_________________

Ich bin da, wer noch?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen AIM-Name MSN Messenger
Fetze
Mini JLI'ler



Anmeldedatum: 23.11.2008
Beiträge: 16

Medaillen: Keine

BeitragVerfasst am: 26.11.2008, 10:43    Titel: Antworten mit Zitat

Okay, vielen Danke schonmal für deine Antwort. Ich habe deinen Beispielcode mal umgesetzt und eigentlich erwartet, das sich VS schon vor dem kompilieren über undefinierte Variablenwerte beschwert.. aber Fehlanzeige! Problem: Ich habe mich seit Projektbeginn darauf verlassen, dass VS das tut (weil das ja hin und wieder doch der Fall ist!) und das ist mittlerweile mehr als ein Jahr her. Confused

Einen ähnlichen Fehler hatte ich schoneinmal, er verschwand jedoch irgendwann kommentarlos wieder.. jetzt muss ich also mal schauen, dass ich nach entsprechenden Stellen suche und diese eliminiere. Da der Fehler bereits in der Init-Funktion des Moduls auftritt, bleibt die Fehlerquelle glücklicherweise recht gering.

Gibt es weiterhin bestimmte "Suchtaktiken" oder vllt ein Programm, das Quellcode genau auf nichtinitialisierte Variablen prüft? Das wäre jetzt enorm hilfreich.


Edit: Mich beschleicht gerade das Gefühl, dass meine Programme teilweise auch via "Neu Erstellen" im Deubgmodus kompiliert werden, da ich - anders als vor eingier Zeit - keinen Performanceunterschied mehr zwischen Debug- und Releaseversion feststelle.. oO
Ich verwende Visual Studio C# Express 2005. Die Buildkonfiguration ist "Release", aber ich habe zwecks Umstellung auf x86-Prozessoren auch schonmal an den projektfiles rumgespielt.. wobei ich da nur ebendieses Attribut hinzugefügt habe.

Hier ein Ausschnitt aus der .csproj-Datei:
Code:

  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProductVersion>8.0.50727</ProductVersion>
    <SchemaVersion>2.0</SchemaVersion>
    <ProjectGuid>{09C790A6-0A66-4B38-B475-B8AA7FC84960}</ProjectGuid>
    <OutputType>Exe</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>Testprojekt4</RootNamespace>
    <AssemblyName>Testprojekt4</AssemblyName>
    <PlatformTarget>x86</PlatformTarget>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <PlatformTarget>x86</PlatformTarget>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <PlatformTarget>x86</PlatformTarget>
    <UseVSHostingProcess>false</UseVSHostingProcess>
  </PropertyGroup>
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Dr. Best
Senior JLI'ler


Alter: 33
Anmeldedatum: 17.06.2004
Beiträge: 269
Wohnort: Köln
Medaillen: Keine

BeitragVerfasst am: 26.11.2008, 12:45    Titel: Antworten mit Zitat

Dass der Compiler sich bei im Konstruktor uninitialisierten Klassenmembern nicht beschwert macht schon Sinn. Wenn du z.B. eine sehr primitive Klasse, wie eine Klasse für 3D-Vektoren hast wäre das ziemlich unerwünscht. Wenn du ein Array mit 10000 Vektoren erstellst und der ersteinmal bei jedem einzelnen die Elemente auf Standardwerte setzen würde wäre das eben eine ziemliche Verschwendung. Außerdem kommt es immer mal wieder vor, dass bestimmte Member nur dann relevant sind, wenn die Instanz der Klasse in einem bestimmten Zustand ist. Wenn man z.B. eine Klasse für alle drei D3D Lichttypen hat, ist bei einem direktionalen Licht das Member für die Position egal und es ist in Ordnung wenn da Datenschrott drin ist. Eventuell kannst du aber in den Compilereinstellungen, dafür sorgen, dass bei uninitialisierten Variablen eine Warnung ausgegeben wird (müsstest du mal ein bisschen rumsuchen).

Ansonsten könntest du auch den manuellen Weg gehen. Jeden Konstruktor in jeder Klasse mit einer vollständigen Elementinitialisierungsliste versehen. Ist natürlich eine Sisyphusarbeit, aber wenn du es ein bisschen geschickt angehst kannst du damit in ca. zwei Tagen durch sein und bist das Problem und alle vergleichbaren dann immerhin los. Ich hatte mal etwas ähnliches. Hatte die schlechte Angewohnheit immer einfach in jeden Konstruktor
CPP:
ZeroMemory(this,sizeof(CFoo));

zu schreiben. Das ist spätestens dann nicht mehr gut wenn die Klassen andere Klassen mit ordentlichen Konstruktoren als Datenmember haben oder man Vererbung nutzt. Habe mich dann entschlossen, dass an absolut allen Stellen, wo es benutzt wird rauszunehmen und musste dann auch nachträglich für zahlreiche Klassen und Strukturen Initialisierungslisten schreiben.

Was deine Performanceprobleme angeht kann ich dir auch nicht helfen. Bei den ganzen Compilereinstellungen habe ich auch nicht so den Überblick.

P.S.: Das Problem kann wie gesagt auch andere Ursachen als nicht initialisierte Datenmember haben, also nicht verzweifeln falls du es durch ordentliches initialisieren nicht behoben kriegst Wink .
_________________

Ich bin da, wer noch?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen AIM-Name MSN Messenger
Fetze
Mini JLI'ler



Anmeldedatum: 23.11.2008
Beiträge: 16

Medaillen: Keine

BeitragVerfasst am: 28.11.2008, 22:59    Titel: Antworten mit Zitat

Okay, langsam komme ich der Verzweiflung doch immer näher.

Habe mein Projekt als Backup gespeichert und dann beim ausgeführten Projekt den gesamten unwichtigen code hrausgeschmissen bis nur noch etwa 10 zeilen drin waren. Fehler besteht weiterhin. "Gut", dachte ich mir, "muss es am verwendeten Modul und nicht dem Programm selbst liegen". Da das ganze schon während der Init-Funktion abstürzt, bleibt mir glücklicherweise 99% des Debuggings erspart.. allerdings ist e mir ein Rätsel, wie das ganze schon dort abstürzen kann.

Nicht initialisierte Variablen fallen weg, da dort aus keiner einzigen Variable gelesen wird, nur geschreiben (wenn überhaupt). Ich habe festgestellt, dass das Projekt einwandfrei im Releasemode läuft, wenn ich den folgenden part auskommentiere dessen Aufgabe es ist, eingebettete Dateien zu extrahieren und als "eigenständige" Dateien abzuspeichern. Daraufhin werden sie eingelesen und wieder gelöscht.
CPP:
         Assembly   asm         = Assembly.GetAssembly(typeof(ZweiDe));
         byte[]      buffer;
         Stream      str;
         int         len;
         string      tempName;

         for (int i = 0; i < asm.GetManifestResourceNames().Length; i++)
         {
            tempName = asm.GetManifestResourceNames()[i];
            Console.WriteLine("{0}: {1}", i, tempName);
            if (tempName.Contains("_zweide_internal_circle256.png"))
            {
               Console.WriteLine("\tbegin");
               str = asm.GetManifestResourceStream(tempName);
               len = (int)str.Length;
               buffer = new byte[len];
               str.Read(buffer, 0, len);
               str.Close();
               File.WriteAllBytes("_zweide_internal_circle256.png", buffer);
               Console.WriteLine("\tend");
            }
            else if (tempName.Contains("_zweide_internal_fnt8.fnt"))
            {
               Console.WriteLine("\tbegin");
               str = asm.GetManifestResourceStream(tempName);
               len = (int)str.Length;
               buffer = new byte[len];
               str.Read(buffer, 0, len);
               str.Close();
               File.WriteAllBytes("_zweide_internal_fnt8.fnt", buffer);
               Console.WriteLine("\tend");
            }
            else if (tempName.Contains("_zweide_internal_fnt8.png"))
            {
               Console.WriteLine("\tbegin");
               str = asm.GetManifestResourceStream(tempName);
               len = (int)str.Length;
               buffer = new byte[len];
               str.Read(buffer, 0, len);
               str.Close();
               File.WriteAllBytes("_zweide_internal_fnt8.png", buffer);
               Console.WriteLine("\tend");
            }
            Console.WriteLine(".");
         }

         Console.WriteLine("1"); // LAST LOG!
         circleTex = Texture.Load("_zweide_internal_circle256.png", Texture.TexFlag.Smooth | Texture.TexFlag.MipMap | Texture.TexFlag.EdgeClamp);
         circleTex.AnisotropicLevel = Texture.GetMaxAnisoLevel();
         defaultFont = Font.Load("_zweide_internal_fnt8.fnt");
         Console.WriteLine("2");

         File.Delete("_zweide_internal_circle256.png");
         File.Delete("_zweide_internal_fnt8.fnt");
         File.Delete("_zweide_internal_fnt8.png");
         Console.WriteLine("3");


Die Console enthält gegen Programmabsturz alle Einträge bis zu (inkl.) "1".

Möglicherweise ein heißer Tip: Wenn ich "Assembly.GetAssembly(..)" durch "Assembly.GetExecutingAssembly()" ersetze, stürzt das Programm direkt(!!) in der Assembly-Zeile ab.

Irgendwie sehe ich hier das Problem nicht.. mache ich was grundsätzlich falsc?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Dr. Best
Senior JLI'ler


Alter: 33
Anmeldedatum: 17.06.2004
Beiträge: 269
Wohnort: Köln
Medaillen: Keine

BeitragVerfasst am: 29.11.2008, 11:30    Titel: Antworten mit Zitat

Ist jetzt nur so eine Idee, aber vielleicht hilft es ja. Die Zeilen hier kommen mir so vor, als könnten sie falsch sein:
CPP:
               len = (int)str.Length;
               buffer = new byte[len];
               str.Read(buffer, 0, len);

Ich kenne mich mit C# nicht aus, aber ich geh mal davon aus, dass die strings auch dort null-terminated sind. Dann müsste buffer nicht die größe len sondern len+1 haben. Und str.Read(...) würde 1 hinter das Ende des buffers schreiben. Wär also eine Zugriffsverletzung. Richtig sähe es so aus:
CPP:
               len = (int)str.Length;
               buffer = new byte[len+1];
               str.Read(buffer, 0, len);


Erklärt allerdings nicht warum du es mit nem anderen Code schon in der ersten Zeile zum Absturz kriegst. Aber vielleicht machst du den gleichen Fehler ja noch vorher an einer anderen Stelle. Bedenke, dass der Fehler nicht in dem Codeabschnitt stecken muss, auch wenn er sich nur bemerkbar macht, wenn der Code mitausgeführt wird.
_________________

Ich bin da, wer noch?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen AIM-Name MSN Messenger
Fetze
Mini JLI'ler



Anmeldedatum: 23.11.2008
Beiträge: 16

Medaillen: Keine

BeitragVerfasst am: 29.11.2008, 11:36    Titel: Antworten mit Zitat

Ich hab das mal ausprobiert (auch im Vorherigen Codeabschnitt), allerdings besteht der Fehler weiterhin - das wars also nicht, trotzdem danke Smile
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
AFE-GmdG
JLI MVP
JLI MVP


Alter: 44
Anmeldedatum: 19.07.2002
Beiträge: 1374
Wohnort: Irgendwo im Universum...
Medaillen: Keine

BeitragVerfasst am: 04.02.2009, 15:41    Titel: Antworten mit Zitat

Ist das Thema noch aktuell?

Ich bin ein sehr guter C#-ler, das kann ich ohne rot zu werden von mir behaupten.

Zum (vor)letzten Post:
Strings in C# sind nicht NullTerminiert - sondern eine Klasse, welche die Länge und die Daten getrennt verwaltet speichert.
_________________
CPP:
float o=0.075,h=1.5,T,r,O,l,I;int _,L=80,s=3200;main(){for(;s%L||
(h-=o,T= -2),s;4 -(r=O*O)<(l=I*I)|++ _==L&&write(1,(--s%L?_<(L)?--_
%6:6:7)+\"World! \\n\",1)&&(O=I=l=_=r=0,T+=o /2))O=I*2*O+h,I=l+T-r;}
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Fetze
Mini JLI'ler



Anmeldedatum: 23.11.2008
Beiträge: 16

Medaillen: Keine

BeitragVerfasst am: 04.02.2009, 16:09    Titel: Antworten mit Zitat

Mittlerweile hat sich das Problem gelöst, es war ein externes Modul - genauergesagt: Eine fehlerhafte Implementierung eines externen Moduls in C#. Durch die auskommentierung zweier unwesentlicher Zeilen (Bestimmung der Modulversion) funktioniert alles bestens Smile
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
AFE-GmdG
JLI MVP
JLI MVP


Alter: 44
Anmeldedatum: 19.07.2002
Beiträge: 1374
Wohnort: Irgendwo im Universum...
Medaillen: Keine

BeitragVerfasst am: 04.02.2009, 16:31    Titel: Antworten mit Zitat

alles klar.
_________________
CPP:
float o=0.075,h=1.5,T,r,O,l,I;int _,L=80,s=3200;main(){for(;s%L||
(h-=o,T= -2),s;4 -(r=O*O)<(l=I*I)|++ _==L&&write(1,(--s%L?_<(L)?--_
%6:6:7)+\"World! \\n\",1)&&(O=I=l=_=r=0,T+=o /2))O=I*2*O+h,I=l+T-r;}
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    JLI Spieleprogrammierung Foren-Übersicht -> Entwicklung Alle Zeiten sind GMT
Seite 1 von 1

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.


Powered by phpBB © 2001, 2005 phpBB Group
Deutsche Übersetzung von phpBB.de

Impressum