fpUnit - AssertEquals gives Access violation

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

fpUnit - AssertEquals gives Access violation

Graeme Geldenhuys-2
Hi,

AssertEquals always gives an Access violation error for some reason.
First some background info is needed....

I first write some of my tests using AssertTrue as follows:
  AssertTrue('Failed on 2', posClean = lNode1.ObjectState);

This just raise the exception when they didn't match. I preferred to
have the style expected <> but got <> message.  So I started change
those tests to the following:

  AssertEquals('Failed on 5', ObjectStateToString(posClean),
    ObjectStateToString(lList.ObjectState));

This worked fine, but after doing this for a while I realized I am
typing my life away with all those ObjectStateToString() calls.  Then
I thought, why don't I create a new AssertEquals method for my
projects that take TPerObjectState as parameters.  So I created this
in my custom test case class.

{ defined under Public }
procedure TM2TestCase.AssertEquals(const pMessage: string; pExpected,
  pActual: TPerObjectState);
begin
  AssertEquals(pMessage,
    ObjectStateToString(pExpected),
    ObjectStateToString(pActual));
end;

BTW: TPerObjectState is define as follows...

  TPerObjectState = (
                      posEmpty,
                      posPK,
                      posCreate,
                      posUpdate,
                      posDelete,
                      posDeleted,
                      posClean
                     ) ;



Now changing my test to the following, which is much easier to type and read:

  AssertEquals('Failed on 1', posEmpty, lLang.ObjectState);


Finally, getting back to the problem.  Using this new AssertEquals
always gives me a Access violation error.  I know there is a
AssertEquals that uses TClass, could that interfere with this?  I even
tried changing my new AssertEquals to use a different name
AssertEqualsObjState(), but that didn't help either.

What could be causing the problem?

Regards,
  - Graeme -


--
There's no place like 127.0.0.1
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpUnit - AssertEquals gives Access violation

Graeme Geldenhuys-2
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>"

Regards,
  - Graeme -


On 06/10/06, Graeme Geldenhuys <[hidden email]> wrote:

> Hi,
>
> AssertEquals always gives an Access violation error for some reason.
> First some background info is needed....
>
> I first write some of my tests using AssertTrue as follows:
>   AssertTrue('Failed on 2', posClean = lNode1.ObjectState);
>
> This just raise the exception when they didn't match. I preferred to
> have the style expected <> but got <> message.  So I started change
> those tests to the following:
>
>   AssertEquals('Failed on 5', ObjectStateToString(posClean),
>     ObjectStateToString(lList.ObjectState));
>
> This worked fine, but after doing this for a while I realized I am
> typing my life away with all those ObjectStateToString() calls.  Then
> I thought, why don't I create a new AssertEquals method for my
> projects that take TPerObjectState as parameters.  So I created this
> in my custom test case class.
>
> { defined under Public }
> procedure TM2TestCase.AssertEquals(const pMessage: string; pExpected,
>   pActual: TPerObjectState);
> begin
>   AssertEquals(pMessage,
>     ObjectStateToString(pExpected),
>     ObjectStateToString(pActual));
> end;
>
> BTW: TPerObjectState is define as follows...
>
>   TPerObjectState = (
>                       posEmpty,
>                       posPK,
>                       posCreate,
>                       posUpdate,
>                       posDelete,
>                       posDeleted,
>                       posClean
>                      ) ;
>
>
>
> Now changing my test to the following, which is much easier to type and read:
>
>   AssertEquals('Failed on 1', posEmpty, lLang.ObjectState);
>
>
> Finally, getting back to the problem.  Using this new AssertEquals
> always gives me a Access violation error.  I know there is a
> AssertEquals that uses TClass, could that interfere with this?  I even
> tried changing my new AssertEquals to use a different name
> AssertEqualsObjState(), but that didn't help either.
>
> What could be causing the problem?
>
> Regards,
>   - Graeme -
>
>
> --
> There's no place like 127.0.0.1
>


--
There's no place like 127.0.0.1
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: fpUnit - AssertEquals gives Access violation

Vincent Snijders
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  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: fpUnit - AssertEquals gives Access violation

Graeme Geldenhuys-2
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 <[hidden email]> 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  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>


--
There's no place like 127.0.0.1
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: fpUnit - AssertEquals gives Access violation

Dean Zobec
Graeme Geldenhuys ha scritto:

> 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)
>
Hmm, no idea where the problem is, can you send me the example that
shows the av, maybe with the code I can find it.
Dean
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal