grizto
Aktives Mitglied
Thread Starter
- Dabei seit
- 27.11.2004
- Beiträge
- 398
- Reaktionspunkte
- 9
Morgen
Ich hab ein seltsames Problem, mit dem ich nicht weiterkomme, vor allem wenn man als sonst Java-progger c++ macht, und aufeinmal kommt der speicher ins spiel
Wenn in unserem Schachprogramm (rund 32 klassen, qt, opengl, openal) eine Klasse ein Funktion einer anderen Klasse, also zur Laufzeit eher eines anderen objekts aufruft, beendet sich die app und der bericht zeigt follgendes
anscheinend will er auf einen speicherbereich zugreifen, auf den er nich zugreifen darf.
Das geschieht zBsp, wenn unsere Kontrollklasse, ein Textlabel der GUI ändern will. Aber die selbe kotntrollklasse kann ein Textfeld in der GUI klasse problemlos ändern.
ebenso stürzt es ab, wenn die Kontrollklasse auf die Schnittstellenklasse der KI zugreift
Schmeisse ich die Labeländerung sowie den zugriff auf die Schnittstellenklasse raus (was den spielspaß mindert ) funktioniert alles.
Das Programm läuft ohne Probleme unter Linux (zum glück ist das für den Prof entscheidend) aber ich hätte es nunmal gerne auch bei mir zum laufen gebracht.
Ich hab ein seltsames Problem, mit dem ich nicht weiterkomme, vor allem wenn man als sonst Java-progger c++ macht, und aufeinmal kommt der speicher ins spiel
Wenn in unserem Schachprogramm (rund 32 klassen, qt, opengl, openal) eine Klasse ein Funktion einer anderen Klasse, also zur Laufzeit eher eines anderen objekts aufruft, beendet sich die app und der bericht zeigt follgendes
Date/Time: 2007-03-28 09:43:29.124 +0200
OS Version: 10.4.9 (Build 8P135)
Report Version: 4
Command: MainWindow
Path: /Users/grizto/Desktop/Virtual Patt 2000/MainWindow.app/Contents/MacOS/MainWindow
Parent: WindowServer [102]
Version: ??? (???)
PID: 12584
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0000005f
Thread 0 Crashed:
0 MainWindow 0x0001c020 Uci::getMatt() + 16 (uci.cpp:22)
1 MainWindow 0x0000d16c ChessControl::compMove() + 240 (chessControl.cpp:336)
2 MainWindow 0x00023a4c StandardField:aintObject() + 556 (standardField.cpp:41)
3 MainWindow 0x000219bc NoAnimation:aintObject() + 160 (noAnimation.cpp:19)
4 MainWindow 0x0000a458 Board:aintObject() + 196 (board.cpp:187)
5 MainWindow 0x0000b0c0 ChessControl:aint() + 60 (chessControl.cpp:52)
6 MainWindow 0x0001d534 GLWidget:aintGL() + 896 (glwidget.cpp:133)
7 QtOpenGL 0x0070ab98 QGLWidget::glDraw() + 192 (icplusplus.c:28)
8 MainWindow 0x0001ce6c GLWidget::timeout() + 56 (glwidget.cpp:35)
9 MainWindow 0x00028470 GLWidget::qt_metacall(QMetaObject::Call, int, void**) + 424 (moc_glwidget.cpp:81)
10 QtCore 0x01942010 QMetaObject::activate(QObject*, int, int, void**) + 1192 (icplusplus.c:28)
11 QtCore 0x01942540 QObject::event(QEvent*) + 116 (icplusplus.c:28)
12 QtGui 0x01014428 QApplicationPrivate::notify_helper(QObject*, QEvent*) + 544 (qsystemtrayicon_mac.mm:346)
13 QtGui 0x010168b0 QApplication::notify(QObject*, QEvent*) + 4500 (qsystemtrayicon_mac.mm:346)
14 QtGui 0x01050018 QApplicationPrivate::globalEventProcessor(OpaqueEventHandlerCallRef*, OpaqueEventRef*,
anscheinend will er auf einen speicherbereich zugreifen, auf den er nich zugreifen darf.
Das geschieht zBsp, wenn unsere Kontrollklasse, ein Textlabel der GUI ändern will. Aber die selbe kotntrollklasse kann ein Textfeld in der GUI klasse problemlos ändern.
ebenso stürzt es ab, wenn die Kontrollklasse auf die Schnittstellenklasse der KI zugreift
Schmeisse ich die Labeländerung sowie den zugriff auf die Schnittstellenklasse raus (was den spielspaß mindert ) funktioniert alles.
Das Programm läuft ohne Probleme unter Linux (zum glück ist das für den Prof entscheidend) aber ich hätte es nunmal gerne auch bei mir zum laufen gebracht.
Zuletzt bearbeitet: