2008-10-18 5 views
5

Im folgenden Fall rufe ich eine Func mit Zeiger an sie übergeben, aber in der aufgerufenen Funktion zeigt der Parameter den Zeiger Wert als etwas total falsch. Etwas wie unten.Warum ändert sich ein Zeiger während des Funktionsübergangs?

bool flag = Func(pfspara);--> pfspara = 0x0091d910 

bool Func(PFSPARA pfspara) --> pfspara = 0x00000005 
{ 
    return false; 
} 

Warum pfspara Wechsel zu einem gewissen falschen Zeiger? Ich kann das Problem im Debug nicht reproduzieren, nur in der Produktion.

Danke.

+0

Konnten Sie ein kleines, vollständiges Beispiel eines Programms bekannt geben, das dieses Problem zeigt? Es ist schwer zu sagen, was nur mit Code-Schnipsel passieren könnte. –

+0

Ich bin bei dir; das Definieren der Typen ist ein absolutes Minimum für diese Art von Frage (bis einschließlich Funktionssignaturen). Also, ist das C, C++ oder etwas anderes? –

+0

Ich nahm C++ wegen Bool an. Wenn ich falsch liege, kann er das Tag ändern. – Bernard

Antwort

1

Im Allgemeinen sollte dies nie passieren. Probleme, die diese Art von Symptomen verursachen können, umfassen Inkompatibilität in den Kompilierungsoptionen zwischen den aufrufenden und den aufrufenden Modulen, schlechtes Umwandeln von Elementfunktionszeigern oder einfach Compilerfehler. Sie müssen viel mehr Details zu Ihrem Problem angeben: Zeigen Sie den echten Code, geben Sie Ihren Compiler an, geben Sie an, was die Kompilierungsflags Debug oder Produktion sind, etc.

8

Wenn Sie versuchen, optimierten Code zum Beispiel zu debuggen In Visual Studio können Sie sich nicht immer darauf verlassen, dass der Debugger die Werte von Variablen korrekt anzeigt - insbesondere nicht, wenn die Variable nicht verwendet wird, so dass der Compiler sie wahrscheinlich optimiert.

Versuchen Sie, diese stattdessen:

bool Func(PFSPARA pfspara) 
{ 
    printf("%x\n", pfspara); 
    return false; 
} 
0

Neben Rasmus' Kommentare, finde ich es im Allgemeinen wert ist als Release-Build zu prüfen, ob auch in einem Debug-Build das Problem auftritt. Wenn Sie feststellen, dass echte Probleme in einem Releasebuild, aber nicht im Debugbuild auftreten, liegt es oft an einem Fehler, der durch die Optimierungsprozesse offengelegt wird, z. B. eine nicht initialisierte Variable. Es besteht eine echte Gefahr, wenn Sie die meisten Tests in einem Debug-Build durchführen, um das Problem zu vermeiden, das Sie hier sehen, und dann einen Release-Build zu versenden. IMO, wenn Sie nicht eine gute Regressionstestsuite (vorzugsweise automatisiert) haben, würde ich vermeiden, opmatischen Code zu versenden.

0

Es klingt wie ein Pufferüberlauf-Problem für mich - etwas überschreibt diese Variable. Aber wie in anderen Antworten erwähnt, gibt es keine Möglichkeit, sicher zu sagen, ohne einen tatsächlichen Code zu verwenden.

0

Es klingt für mich wie Sie auf dem Stapel kritzeln ... irgendwo in Ihrem Code ist ein Puffer auf dem Stapel überfüllt, oder Sie nehmen die Adresse eines Objekts auf dem Stapel und schreiben nach dem Funktion kehrt zurück. Dies führt dazu, dass Ihr Stack beschädigt wird.

Dies kann nur im Freigabemodus passieren, da die Stapelzuordnungen aufgrund der Optimierung und des Ausschlusses von "Schutz" -Blöcken, die zur Prüfung dieser Art von Bedingung verwendet werden, unterschiedlich sind.

Verwandte Themen