✔ C/C++: Finde Grund für "Stack overflow" nicht ...

vfl_freak

vfl_freak

Premium-User
Moin,

ich bekomme mit meinem Server-Programm bei einer bestimmten Funktion kurz nach dem Programmstart einen "Stack overflow" (siehe Bild-1). Hier wird eine Funktion mit schätzungsweise 3500 - 5000 Zeilen Code aufgerufen. Der Fehler tritt aber gleich zu Beginn auf, nach ca. 5 Deklarationen, wenn ich dann Zugruff auf eine BTrieve-Tabelle nehmen will.

Dieser Fehler (und auch die weiter unten aufgeführten Meldungen) kommen nur auf einem bestimmten Rechner (Server mit Linux als BS und aufgesetzem XP). Auf anderen, reinen XP-Rechnern, auf denen diese Anwendung auch läuft, kommen diese Meldungen und auch der Stack overflow nicht.

Wenn ich nun in der Maske aus Bild-1 auf <Unterbrechen> klicke und mir die Aufrufliste anschaue, sehe ich leider nur die Angaben in Bild-2 - keine Hinweis auf meine Sourcen ...

Bei Starten der Debug-Version erhalte ich zum einen div. Angaben zu nicht gefundenen Programmdatenbanken in der Art:
C++: 
"#GSCRMServer.exe": "F:\orga\internet\crmserver\#GSCRMServer.exe" geladen, Symbole wurden geladen.
"#GSCRMServer.exe": "C:\WINDOWS\system32\ntdll.dll" geladen, Cannot find or open the PDB file
"#GSCRMServer.exe": "C:\WINDOWS\system32\kernel32.dll" geladen, Cannot find or open the PDB file
Das heißt ja wohl, dass hier irgendwelche Symboltabellen fehlen, richtig?
Benötige ich sie zwingend?
Wie komme ich da dran?

Auf diesem speziellen Rechner (s. u.) stehen dann zwischen diesen Ausgaben folgende drei Zeilen
C++: 
Eine Ausnahme (erste Chance) bei 0x7c812afb in #GSCRMServer.exe: 0x000006D9: In der Endpunktzuordnung sind keine weiteren Endpunkte verfügbar.
...
Eine Ausnahme (erste Chance) bei 0x7c812afb in #GSCRMServer.exe: Microsoft C++-Ausnahme: EPSCoreException an Speicherposition 0x0012d7d0
...
Eine Ausnahme (erste Chance) bei 0x7c812afb in #GSCRMServer.exe: 0x000006D9: In der Endpunktzuordnung sind keine weiteren Endpunkte verfügbar.
Leider hat mich hierzu eine Websuche nicht wirklich schlauer gemacht ...

An der Stelle, an der die Anwendung dann abschmirrt ist nichts wirklich auffällig und ich vermute zudem, dass ich evtl. Speicher an anderer Stelle kaput schriebe - nur wo?
Durch das Anstossen dieser Funktion im zugehörigen Clientprogramm werden zunächst noch einige andere CMDs an das Serverprogramm gesendet, um verschiedene Daten aus der DB zu ermitteln. Hierbei ist im Debugger nichts auffällig gewesen.

Ich bin hier absolut ratlos, wie und wonach in nun eigentlich suchen sollte und hoffe, das mir jemand weiterhelfen.

Danke und Gruß
Klaus
 

Anhänge

  • CRM-Error_01.jpg
    CRM-Error_01.jpg
    22,1 KB · Aufrufe: 14
  • CRM-Error_02.jpg
    CRM-Error_02.jpg
    47,9 KB · Aufrufe: 18
Zuletzt bearbeitet von einem Moderator:
Hallo Klaus

Erste Sachen die du tun solltest sind ein paar Einstellungen. Unter Debug -> Exceptions machst du überall "Thrown" raus, du willst nur Exceptions angezeigt bekommen wenn sie nie abgefangen werden, nicht wenn sie geworfen werden.

Als nächstes machst du im Callstack einen Rechtsklick auf die entsprechenden Einträge der DLLs die keinen Manem haben (ntdll.dll, ws2_32.dll, usw) und gehst auf "Load From" (oder Load Symbols, kann grad nicht nachsehen, da bei mir alles geladen ist) und wählst "Microsoft Symbol Server", dann erhälst du effektiv die Namen der Funktionen. So lässt es sich vielleicht besser nachvollziehen.

Grüsse
Cromon
 
Hi Cromon,

Danke für die Tipps, das klingt ja schon mal ermutigend :)

Cromon hat gesagt.:
Als nächstes machst du im Callstack einen Rechtsklick auf die entsprechenden Einträge der DLLs die keinen Manem haben (ntdll.dll, ws2_32.dll, usw) und gehst auf "Load From" (oder Load Symbols, kann grad nicht nachsehen, da bei mir alles geladen ist) und wählst "Microsoft Symbol Server", dann erhälst du effektiv die Namen der Funktionen. So lässt es sich vielleicht besser nachvollziehen.
Zum Vergrößern anklicken....
ääh ... "Manem" :confused:
Meinst Du "Namen", oder ?

Das werde ich gleich morgen früh mal testen (habe von hier von zuhause keinen Zugriff) und melde nich dann nochmal !

Danke und Gruß
Klaus
 
Zuletzt bearbeitet:
vfl_freak hat gesagt.:
Hier wird eine Funktion mit schätzungsweise 3500 - 5000 Zeilen Code aufgerufen. Der Fehler tritt aber gleich zu Beginn auf, nach ca. 5 Deklarationen, wenn ich dann Zugruff auf eine BTrieve-Tabelle nehmen will.
Zum Vergrößern anklicken....

Hallo Klaus,

werden dort größere Datenmengen (z.B. Arrays) auf dem Stack erzeugt (also nicht mit "new")?

Gruß
MCoder
 
Moin Cromon,

Cromon hat gesagt.:
Erste Sachen die du tun solltest sind ein paar Einstellungen. Unter Debug -> Exceptions machst du überall "Thrown" raus, du willst nur Exceptions angezeigt bekommen wenn sie nie abgefangen werden, nicht wenn sie geworfen werden.

Als nächstes machst du im Callstack einen Rechtsklick auf die entsprechenden Einträge der DLLs die keinen Manem haben (ntdll.dll, ws2_32.dll, usw) und gehst auf "Load From" (oder Load Symbols, kann grad nicht nachsehen, da bei mir alles geladen ist) und wählst "Microsoft Symbol Server", dann erhälst du effektiv die Namen der Funktionen. So lässt es sich vielleicht besser nachvollziehen.
Zum Vergrößern anklicken....
So, habe das "thrown" jetzt überall entfernt; dann den Fehler erzeugt und dann, wie Du vorgeschlagen hast, die Funktionsnamen über den Symbol Server geladen (was allerdings bei den Einträgen "pscore3.dll" und "w3mif90.dll" nicht klappt - kA, was das für Libs sind). Das Ergebnis - siehe Anlage - finde ich allerdings nicht sehr ermutigend ...

MCoder hat gesagt.:
werden dort größere Datenmengen (z.B. Arrays) auf dem Stack erzeugt (also nicht mit "new")?
Zum Vergrößern anklicken....
So aus dem Stand würde ich sagen NEIN, aber ich prüfe das gerade mal, wobei ich mir gleichzeit diese Mwethoden nochmal im Detail im Debugger anschaue ...

Gruß
Klaus

EDIT
Sehe gerade, dass die beiden o. g. Libs von Pervasive kommen (also mit der BTrieve-DB zusammenhängen). Dies kommt jetzt beim endgültigen Abbrechen des Programms in der Konsole

Eine Ausnahme (erste Chance) bei 0x7c91e8e5 in #GSCRMServer.exe: 0xC00000FD: Stack overflow.
Unbehandelte Ausnahme bei 0x7c91e8e5 in #GSCRMServer.exe: 0xC00000FD: Stack overflow.
C:\Programme\Pervasive Software\PSQL\bin\w3mif190.dll: Cannot find or open the PDB file
C:\Programme\Pervasive Software\PSQL\bin\w3mif190.dll: Cannot find or open the PDB file
C:\Programme\Pervasive Software\PSQL\bin\pscore3.dll: Cannot find or open the PDB file
C:\Programme\Pervasive Software\PSQL\bin\pscore3.dll: Cannot find or open the PDB file
Das Programm "[3032] #GSCRMServer.exe: Systemeigen" wurde mit Code 0 (0x0) beendet.

Wir nutzen auf diesem Rechner wohl eine neuere Version der DB als sonst, aber leider nicht die aktuelle .... muss ich mal bei unsreren Admins
 

Anhänge

  • CRM-Error_03.jpg
    CRM-Error_03.jpg
    78,9 KB · Aufrufe: 11
Zuletzt bearbeitet:
Moin McCoder,


MCoder hat gesagt.:
werden dort größere Datenmengen (z.B. Arrays) auf dem Stack erzeugt (also nicht mit "new")?
Zum Vergrößern anklicken....
Also ... mit "new" wird hier nur ganz wenig erzeugt (und wenn, dann auch sauber mit "delete" wieder freigegeben).
Es wird hier natürlich bei jedem zuerst aufgerufenen CMD ein Struct für die Datenrückgabe deklariert (Größe i.d.R. 512 byte).

Beispiel:
C++: 
#pragma pack(push, 1)
struct ZUSATZDATEN
{
	long crt;			// 1	4	
	char art[3];		// 5	3   VP/GVL/AKQ
	long nummer;		// 8	4   VP-, GVL, AKQ-Nummer
	char email[64];		// 12	64
	BYTE reserve[436];	// 76	436
	BYTE iud;			// 512	1
};
#pragma pack(pop)

...

// und dann bspw.
ZUSATZDATEN myStruct;

Eine der Methoden nutzt auch eine Tabelle mit der bei BTrieve üblichen "variablen Datensatzlänge" (dies bedeutet, dass ich eine fixen Datenteil von bspw. 32 Byte habe, in dem auch als long-Wert die variable Datenlänge -dies können ein paar tausend Byte sein- eingetragen ist.
Bin da jetzt mehrfach mit dem Debugger durchgelaufen, ohne Probleme zu erkennen. Alle Längen bei Kopiervorgängen stimmen, alle gefüllten Variablen passen

Zum Verzweifeln :-(
Gruß
KLaus
 
Zuletzt bearbeitet von einem Moderator:
Hallo,

wa bedeutet eigentlich "...und aufgesetztem XP" ? Läuft XP dort in einer virtuellen Maschine? Möglicherweise steckt das Problem ja etwas tiefer im System drin.


Gruß
MCoder
 
Moin,

nicht ganz, da war ich nicht ganz im Bilde .... :rolleyes:

Das Programm selbst läuft auf einen XP-Server, nur die BTrieve-Datenbank läuft auf einem separaten Linux-Rechner. Es ist zudem eine neuere DB-Version als bisher.

Das Problem wird zudem immer lustiger. Ich habe mir jetzt einen kleinen Textclient in Java gebastelt, mit dem ich das betroffene Kommando (also die beschriebene Funktion) direkt im dem Serverprogramm aufrufen kann. Auch dann knallt dieses Programm beim ersten DB-Open mit dem CallStack-Fehler weg (sogar, wenn ich als allererstes versuche, eine (beliebige) Tabelle zu öffnen. Andere Kommandos und auch weitere Serverprogramme haben dieses Problem nicht. Ebenso läuft mein Programm auf einem anderen XP-Rechner (mit der DB auf einem separaten XP-Rechner) auch problemlos.

Bin zurzeit dabei, die eingangs erwähnten Fehlermeldungen (Endpunktzuordnung und EPSCoreException) näher zu untersuchen. Allerdings gibt das Web dazu auch nicht wirklich viel her ...

Gruß
Klaus
 
So, wir sind nun mittlerweile soweit, dass wir eigentlich ein Problem mit dem Quelltext ausschliessen können. Wenn ich im Debugger in der aufkommenden Meldung mit dem "CallStack Overflow" augf <Weiter> klicke, ist anschließend die Tabelle auch geöffnet und ich kann ganz normal Daten selektieren .....

Das Problem scheint an der Schnittstelle zu DB zu liegen. Unsere Netzwerk-Abteilung ist jetzt erstmal dran :)

Werde das Thema hier somit beenden!

Danke an alle
Gruß
Klaus
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück