Nicht abgefangene Ausnahme in Meiner.exe (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception.
-
So, ich hab ihn da mal angehalten und kann leider nix böses erkennen:
Es ist nicht BOF, nicht EOF, die Feldinhalte sehen heile aus.Gibt es andere Member von CRecordset, wo man drauf achten muss.
-
In welcher Zeiler crasht er denn dann effektiv?
-
Soo, erstmal der Callstack:
KERNEL32! 77e9bbf3() MSVCRT! 78007108() ODBCCR32! 1f8224af() ODBCCR32! 1f824b50() ODBCCR32! 1f82844f() ODBC32! 01618cb8() CRecordset::FetchData(unsigned short 1, long 1, unsigned long * 0x0012f5dc) line 3049 + 35 bytes CRecordset::Move(long 1, unsigned short 1) line 1414 + 27 bytes CRecordset::MoveNext() line 82 + 60 bytes CBasisSetEx::Suche(long 0) line 82
Das Suche ist die Funktion, deren Code ihr ja mittlerweile kennt.
Der Rest ist MFC Code (von unten nach oben):_AFXDBCORE_INLINE void CRecordset::MoveNext() { ASSERT(IsOpen()); Move(1, SQL_FETCH_NEXT); }
[cpp]void CRecordset::Move(long nRows, WORD wFetchType)
{
ASSERT_VALID(this);
ASSERT(m_hstmt != SQL_NULL_HSTMT);// First call - fields haven't been bound (m_nFieldsBound will change)
if (m_nFieldsBound == 0)
{
InitRecord();
ResetCursor();
}if (m_nFieldsBound > 0)
{
// Reset field flags - mark all clean, all non-null
memset(m_pbFieldFlags, 0, m_nFields);// Clear any edit mode that was set
m_nEditMode = noMode;
}// Check scrollability, EOF/BOF status
CheckRowsetCurrencyStatus(wFetchType, nRows);RETCODE nRetCode;
// Fetch the data, skipping deleted records if necessary
if ((wFetchType == SQL_FETCH_FIRST ||
wFetchType == SQL_FETCH_LAST ||
wFetchType == SQL_FETCH_NEXT ||
wFetchType == SQL_FETCH_PRIOR ||
wFetchType == SQL_FETCH_RELATIVE) &&
m_dwOptions & skipDeletedRecords)
{
SkipDeletedRecords(wFetchType, nRows, &m_dwRowsFetched, &nRetCode);
}
else
// Fetch the data and check for errors
nRetCode = FetchData(wFetchType, nRows, &m_dwRowsFetched); // <----// Set currency status and increment the record counters
SetRowsetCurrencyStatus(nRetCode, wFetchType, nRows, m_dwRowsFetched);// Need to fixup bound fields in some cases
if (m_nFields > 0 && !IsEOF() && !IsBOF() &&
!(m_dwOptions & useMultiRowFetch))
{
Fixups();
}
}
[/cpp]RETCODE CRecordset::FetchData(UWORD wFetchType, SDWORD nRow, DWORD* pdwRowsFetched) { RETCODE nRetCode; if (m_nOpenType == forwardOnly && !(m_dwOptions & useExtendedFetch)) { ASSERT(wFetchType == SQL_FETCH_NEXT); AFX_ODBC_CALL(::SQLFetch(m_hstmt)); *pdwRowsFetched = 1; m_bDeleted = FALSE; } else { AFX_ODBC_CALL(::SQLExtendedFetch(m_hstmt, wFetchType, nRow, pdwRowsFetched, m_rgRowStatus)); // <------- (0x01653c98, 1, 1, 0x0012f5dc (1), 0x00774b00 (0)) // Set deleted status m_bDeleted = GetRowStatus(1) == SQL_ROW_DELETED; } CheckRowsetError(nRetCode); return nRetCode; }
Dann kommt nur noch Assemblercode - der hilft uns nix, oder?
-
Hab ich das richtig verstanden?
Er crasht in der Zeile:
AFX_ODBC_CALL(::SQLExtendedFetch(m_hstmt, wFetchType, nRow, pdwRowsFetched, m_rgRowStatus));
?
-
Ja, das ist die letzte lesbare Zeile.
Wenn ich da F11 drücke, kracht es.
-
habe NULL ahnung aber n versuch ist es ja wert
mach doch in der DB "übersichtliche" einträge
so 100 werte
jetzt laufe wie gehabt alle durchwenn du einen bekommst schreibst du in einen logfile den datensatz
und machst dann movenexteventl. immer die datei öffnen und gleich schliessen ( wegen crash )
maybe hilft dir das weiter. wenn es immer der gleiche ist, dann den untersuchen.
ka, ist verzwickt
-
Es ist leider nicht der gleiche.
Ich habe mit mal zusätzlich zum Zähler noch die Tabelle und die aktuelle ID ausgeben lassen. Hab das Trace wieder hochgeladen. http://www.larsaf-iii.de/forum/trace.txt
An mehr Einzelheiten der Zeile komme ich da nicht dran, weil ich in einer Basisklase bin, wo wirklich blos das bekannt ist.
-
Sicher, dass du die neue Datei hochgeladen hast? Sieht für mich genau gleich aus wie die alte.
-
Ups, die neue hatte sich "verflogen". Jetzt passts aber.
-
Wow.
Es wird mysteriösUnd genau deswegen tipp ich einfach darauf, dass du irgendwo anders nen Zeigerfehler hast
-
Zeigerfehler?
Ahhh, geh weg mit dem bösen Wort...Im Ernst: So spontan fällt mir keine Stelle ein, wo ich da Zeiger verwende. Ich werde mal gucken, aber irgendwie fürchte ich, dass ich an der Sache noch lange knabbern werde.
-
Das ist halt meine Erfahrung. Fast jedesmal, wenn ich so einen völlig unerklärlichen Fehler hatte, hat entweder ein Neustart, ein Rebuild All oder das Suchen nach Pointer-Problemen an anderer Stelle geholfen.
-
Neustart und RebuildAll fallen wohl raus, denn die Fehler habe ich schon ziemlich lange drin - so einige Monate bestimmt.
Es funktioniert ja, also habe ich mich nur sporadisch darum gekümmert und bin daran gescheitert, dass kein catch reagiert.Ich habe eben mal "weiter oben" im Callstack geschaut - da ist kein offensichtlicher Zeiger zu finden. Das sind alles Codeschnipsel, die mehrfach im Programm sind und sonst keine Fehler bringen.
Ich habe auch extra einen RebuildAll gemacht - das kommt bei der selben Zahl.
Und Zeigerfehler woanders suchen wird lustig...
Da kann ich nur hoffen, dass es weiterhin nicht schlimm ist und ich es irgendwann finde.
-
Ich hatte mal was, wo mir n Zeiger ganz woanders was zerschoßen hat. Bis ich das gefunden hatte. urks.
-
lad dir mal die debug symbole für dein betriebssystem runter. dann kannst du den funktionsnamen in der kernel32.dll sehen.
http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx
-
Hatte nen Gedankenfehler.... sorry.
Gruss
EB
-
@Debugger: Vielen Dank für den Link
Das war jetzt schon die zweite sehr wichtige Neuigkeit für mich in diesem Tread.
Ich bin ja mal gespannt, was sich noch alles an Features vor mir versteckt...Edit: Leider funktioniert es nicht. Ich habe das installiert, auch für die richtige Service Pack Version - aber es ist immer noch Assembler Code.
Was habe ich vergessen?
-
Klinke mich hier ein bisschen spät ein, aber beim Debuggen fiel mir auf "da war doch was".
Insofern auch von mir erstmal herzlichen Dank für die Tipps. Die Symboltabelle lade ich gerade herunter (vielleicht hilfts ja wirklich).Diese Exception taucht innerhalb unseres Systems permanent auf. Die damaligen Programmierer meinten, das läge an Windows und das kann man ignorieren
. Waren zwar fähige Jungs, aber so ganz glauben mochte ich dies bis jetzt auch nicht. Die Dinger treten aber auch auf, wenn das Programm aktiv nichts macht und der Debugger das Programm angehalten hat.
Aber was soll man mit dieser Aufrufhistorie nach einer erneuten Exception:
KERNEL32! 77e9bbf3() MSVCRTD! _CxxThrowException@8 + 57 bytes VISCondition::wait_all(VISMutex & {...}, unsigned __int64 300000) line 791 VISCondition::wait_all(VISMutex & {...}, unsigned long 300) line 750 + 32 bytes VISThreadPool::_garbage_collect() line 162 VISTPGCollect::begin() line 39 VISThread::_start(void * 0x03a12d68) line 115 KERNEL32! 77e7b388()
Hier wird der Fehler offenbar von CORBA ausgelöst, während er so untätig rumwartet.
Was mich betrifft: ich bin dafür, das auch erstmal weiterhin zu ignorieren. Ansonsten bin ich sehr gespannt, wie es hier weitergeht.
-
Solltest du mit der Installation der Symboldateien Erfolg haben, dann müßten wir uns nochmal austauschen - bei mir hatte es leider keinen Effekt.
Weder unter VC6 noch unter VC7. Ich habe Win2000 Pro.
-
ne, damit kriegst du nicht den windows quellcode.
wenn du es richtig eingebunden hast
bekommst du statt der nummer hier:
KERNEL32! 77e9bbf3()
Den Funktionsnamen. Eventuell kann man was daraus folgern.