framwork macros stepping on test group data

[Justin Jordan]

Hello,

I have the following bit of code in a test

// Read after first write

bool readAfterWriteOneResult = readMockedMemory(&palFLASHInstance, 0, RW_FIFO_SIZE, outBuff);

CHECK_TRUE(readAfterWriteOneResult);

// Fix read fifo pointer which gets trashed by the CHECK_TRUE step for some reason

palFLASHInstance.stateMachine.transientVars.readFIFO_p = &readFIFO;

From the comments you can see that I have troubleshot the issue I am experiencing down to the CHECK_TRUE macro stepping on some member data of a struct declared as a member of the TEST_GROUP.

I have verified that it is the test frame work macro doing this by moving the call to readMockedMemoryout of the macro and setting a breakpoint on CHECK_TRUE.  At that time the pointer isn't stepped on.

I have tried other macros and the same thing happens.  I am not sure why.

Also, the 'mocked memory' isn't a real mock, it is more of fake.  No test frame work mocks are being used is the point, nor no hand crafted 'mocks' that record events and check values.  Just some helper code faking out the memory.

Any thoughts are ideas would be appreciated.

Also, I have been operating under the impression that it is better practice to place data used for a test group in the test group scope than declaring in the global namespace.

Is that reasonable, or is there cons to scoping the data used within a test group to that test group?

Thanks in advance for any help that can be offered.

[James W Grenning]

Hi Justin

Can you show the whole test case and dependeices?

For instance palFLASHInstance: how is it declared and how is it defined?

Is palFLASHInstance on the stack?

Cheers, James

--
You received this message because you are subscribed to the Google Groups "cpputest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cpputest+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cpputest/405d0f38-d593-497f-bc67-c47cdddba1a2n%40googlegroups.com.

---

James Grenning -- Author of Test-Driven Development for Embedded C

wingman-sw.com blog.wingman-sw.com @jwgrenning facebook.com/wingman.sw

Join my live-via-the-web TDD Training

Mobile: +1 847-630-0998

[Justin Jordan]

James,

I am checking if I can share more of the code.

If I shared the test group and this test case would that be sufficient?  Essentially simplify the file down to a single test case.  I don't believe I will actually be able to share the whole code, i.e CUT and fakes/mocks, etc.

WRT palFLASHInstance being on the stack or not, I don't believe it is as it is a member of the TEST_GROUP, basically making it a struct/class member and I don't think the TEST_GROUP instance is declared on the stack, correct?. 

Should be statically allocated, correct?

pseudo example

TEST_GROUP(PAL_NAND)

{

    palFLASHClass_st palFLASHInstanceDefaults = { .memberData = blahblah, }; // blahblah is part of test group as well, palFLASHClass_st is the typedef struct from the NAND flash driver header.

    palFLASHClass_st palFLASHInstance = palFLASHInstanceDefaults;

   

    setup

    {

       memcpy((void*)&palFLASHInstance, (void*)&palFLASHInstanceDefaults, sizeof(palFLASHClass_st)); // Set everything back to default

    }

}

Thanks for looking and reaching out

To view this discussion on the web visit https://groups.google.com/d/msgid/cpputest/6D0BEF01-18EA-41D9-84FD-435B02A44429%40grenning.net.

[James W Grenning]

If you take the CHECK out, there is no corruption?

What is outbuf? Is it written to? Where is it declared, defined, initialized? Its name implies that stuff is written there.

I've looked into the CHECK_TRUE macro and the value is simply passed through. I suspect some memory corruption.

You might experiment one at a time:

Move the TEST_GROUP data to file scope
Comment out the memcpy in setup

75DED67B-A03E-4DF2-A56B-71E4B1401F9F

[Justin Jordan]

James,

Thank you, I think I have found the issue.

The corruption still exists even if the check is removed.

The driver makes it appear that you configure it with its own readFIFO on init.

Later on, when you want to use the read api of the driver, you have to give it another readFIFO.  I thought that was odd, cause it is already configured with one.

The one passed in using the readAPI stomps on the configured one, and I was declaring the one passed in through the readAPI on the stack.

I haven't proven that is the problem yet, but on my way there.

Thanks,

Justin

To view this discussion on the web visit https://groups.google.com/d/msgid/cpputest/75C0594E-899D-4AD3-94EA-E5B75CFEA9FC%40grenning.net.

[Justin Jordan]

James,

That was it, the secondary readFIFO declared on the stack.

Thanks for your help.

[James W Grenning]

Justin

Good to hear you are on your way. You just experienced a handy thing about test cases. You can make experiments to gather facts.

Cheers, James

To view this discussion on the web visit https://groups.google.com/d/msgid/cpputest/75C0594E-899D-4AD3-94EA-E5B75CFEA9FC%40grenning.net.

--
You received this message because you are subscribed to the Google Groups "cpputest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cpputest+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cpputest/CADX8vCxT1MREBq%3DzEA-OGgZtrja1%2BNURfK-TtbRtmOKypYbivA%40mail.gmail.com.

75DED67B-A03E-4DF2-A56B-71E4B1401F9F