Here is the backtrace. I removed all other Assert tests, so only the one that causes the problem is executed.
What is strange though, is that I created a new test that only creates the object and then tests the ObjectState. It it works, but all the other actual tests don't. I hate such problems! :-) Graeme. -------------- Start --------------- [New Thread -1216787536 (LWP 20619)] [Switching to Thread -1213515552 (LWP 20607)] Breakpoint 1, 0x0805f036 in fpc_raiseexception () (gdb) bt #0 0x0805f036 in fpc_raiseexception () #1 0x082189d9 in FPCUNIT_TASSERT_$__FAIL$ANSISTRING () #2 0xb7f04ac0 in ?? () #3 0xb7a69200 in ?? () #4 0x082189ff in FPCUNIT_TASSERT_$__ASSERTTRUE$ANSISTRING$BOOLEAN () #5 0xb7f04ac0 in ?? () #6 0x08218b45 in FPCUNIT_TASSERT_$__ASSERTEQUALS$ANSISTRING$ANSISTRING$ANSISTRING () #7 0x080a0202 in TNODEDATATEST__ASSERTEQUALS (PMESSAGE=0x8350cf0, PEXPECTED=POSDELETED, PACTUAL=POSCLEAN, this=0xb7a77a68) at NodeData_test.pas:89 #8 0x080a1cb7 in TNODEDATATEST__TESTNODECOMPOUND_SAVE2 (this=0xb7a77a68) at NodeData_test.pas:408 #9 0x0821abf1 in FPCUNIT_TTESTCASE_$__RUNTEST () #10 0x0821ab38 in FPCUNIT_TTESTCASE_$__RUNBARE () #11 0x0821ba67 in FPCUNIT_PROTECTTEST$TTEST$TTESTRESULT () #12 0x0821bb61 in FPCUNIT_TTESTRESULT_$__RUNPROTECTED$TTEST$TPROTECT () #13 0x0821ba9e in FPCUNIT_TTESTRESULT_$__RUN$TTESTCASE () #14 0xb7a77a68 in ?? () #15 0xb7a7cb68 in ?? () #16 0x0821aaeb in FPCUNIT_TTESTCASE_$__RUN$TTESTRESULT () #17 0x0821b4f1 in FPCUNIT_TTESTSUITE_$__RUNTEST$TTEST$TTESTRESULT () #18 0x083ee660 in _$FPCUNIT$_Ld19 () ---Type <return> to continue, or q <return> to quit--- #19 0x0821b4cb in FPCUNIT_TTESTSUITE_$__RUN$TTESTRESULT () #20 0x00000007 in ?? () #21 0xb7a7cb68 in ?? () #22 0xb7a77808 in ?? () #23 0x00000000 in ?? () (gdb) -------------- Finish ---------------- On 06/10/06, Vincent Snijders <[EMAIL PROTECTED]> wrote:
Graeme Geldenhuys schreef: > Oh, I forgot to mention. If the ObjectStates match, the test passes > fine, and doesn't give an access violation. > > While creating the new AssertEquals method, I purposefully created a > failure with then gives the access violation, instead to the > comparison message I expected: > "Failing on 1: Expected <posClean> but got <posEmpty>" > Try creating a back trace, maybe that gives some insight. Vincent _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
-- There's no place like 127.0.0.1 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
