Bad access in source or test code

[Jafet Montesdeoca]

 Hello,

 second time whit this issue. This time without attaching the code.

 I have the following situation.

 If I execute two different test in the same function it works. However, if I execute these two tests one in a function it fails with the topic of this issue.

 About this second fail case. If I comment one of the function it works, whatever the function. It works.

 CODE:

int setDelay(const float delay, const uint32_t laserNumber) {

    const uint32_t delays_IDs[] = {

        DELAY1_OFFSET,

        DELAY2_OFFSET,

    };

    const uint32_t delay_idx = laserNumber - 1;

    if (ARRAY_SIZE(delays_IDs) <= delay_idx) {

        // Invalid argument

        return E_WRITE_DATA_SET_DELAY;

    }

    uint32_t addr = QN100_BASE_ADDRESS + delays_IDs[delay_idx];

    writeParams wParams = {

        .addr = addr,

        .data = (uint32_t)float_to_fixed(delay),

    };

    return write32(&wParams);

} TEST CODE:

For both situations.

writeParams wParams;

float delay;

int result;

uint32_t fixed_delay;

void setUp(void) {

    delay = 0.0;

    result = 0;

    fixed_delay = 0;

    wParams.addr = 0;

    wParams.data = 0;

}

WORKING TEST CODE:

void test_setDelay_both_valid_laser(void) {

    delay = 5.0f;

    fixed_delay = 0x00050000;

    float_to_fixed_CMockExpectAndReturn(__LINE__, delay, fixed_delay);

    wParams.addr = QN100_BASE_ADDRESS + DELAY1_OFFSET;

    wParams.data = fixed_delay;

    printf("UT ADDR 0x%08LX DATA 0x%08LX\r\n", wParams.addr, wParams.data);

    write32_CMockExpectAndReturn(__LINE__, &wParams, SUCCESS);

    result &= setDelay(delay, 1);

    TEST_ASSERT_EQUAL(SUCCESS, result);

    /* ---------------------------------------------------------------------- */

   

    delay = 7.5f;

    fixed_delay = 0x00078000;

    float_to_fixed_CMockExpectAndReturn(__LINE__, delay, fixed_delay);

    wParams.addr = QN100_BASE_ADDRESS + DELAY2_OFFSET;

    wParams.data = fixed_delay;

    printf("UT ADDR 0x%08LX DATA 0x%08LX\r\n", wParams.addr, wParams.data);

    write32_CMockExpectAndReturn(__LINE__, &wParams, SUCCESS);

    result &= setDelay(delay, 2);

    TEST_ASSERT_EQUAL(SUCCESS, result);

}

FAIL TEST CODE:

void test_setDelay_valid_laser_number_one(void) {

    delay = 5.0f;

    fixed_delay = 0x00050000;

    float_to_fixed_CMockExpectAndReturn(__LINE__, delay, fixed_delay);

    wParams.addr = QN100_BASE_ADDRESS + DELAY1_OFFSET;

    wParams.data = fixed_delay;

    printf("UT ADDR 0x%08LX DATA 0x%08LX\r\n", wParams.addr, wParams.data);

    // write32_CMockIgnoreAndReturn(__LINE__, SUCCESS);

    write32_CMockExpectAndReturn(__LINE__, &wParams, SUCCESS);

    result &= setDelay(delay, 1);

    TEST_ASSERT_EQUAL(SUCCESS, result);

}

void test_setDelay_valid_laser_number_two(void) {

    delay = 7.5f;

    fixed_delay = 0x00078000;

    float_to_fixed_CMockExpectAndReturn(__LINE__, delay, fixed_delay);

    wParams.addr = QN100_BASE_ADDRESS + DELAY2_OFFSET;

    wParams.data = fixed_delay;

    printf("ADDR 0x%08LX DATA 0x%08LX\r\n", wParams.addr, wParams.data);

    // write32_CMockIgnoreAndReturn(__LINE__, SUCCESS);

    write32_CMockExpectAndReturn(__LINE__, &wParams, SUCCESS);

    result = setDelay(delay, 2);

    TEST_ASSERT_EQUAL(SUCCESS, result);

}

Thank you very much. All the best.

[mvandervoord]

Hi. 

I'm not seeing anything obvious just from looking but I'm happy to help figure it out. Can you provide the full error message (for example, is that an error from cmock? the compiler? the runtime?). It also might be helpful to know how you're running this... what version of CMock & Unity? Running from Ceedling, using the runner generator, or are you building your own test runners?

Unrelated, I'm curious: Is there a reason you call write32_CMockExpectAndReturn directly instead of using the macro API: write32_ExpectAndReturn() ? The latter allows more flexibility, is more future proof, and less typing. ;)

Mark

[David Good]

I have a question related to this thread (the literal thread) and not the subject of the thread : Why does it appear that sometimes I only see Mark's reply but not the original question ? Is there some other way these questions are coming in ?

Just curious .

--David

--
You received this message because you are subscribed to the Google Groups "ThrowTheSwitch Forums" group.
To unsubscribe from this group and stop receiving emails from it, send an email to throwtheswitc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/throwtheswitch/2597d44d-3b6c-4b19-8f09-4fbf233648den%40googlegroups.com.

[Mark Vander Voord]

David:

That's a really good question. Google Groups has been a mess lately. I also didn't see this original question in my email... I didn't notice it until I went to the forum to see how the spam management was going. I'm not sure why it wasn't sent out... it's not marked as "pending" so Google thinks it was sent.

Add this to the list of reasons we need to migrate to something better. :/

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/throwtheswitch/CALMFhSwwL5wuKVoaFf1i%2BVf6ujvS3A5hN%2B1_5sHrRvrgjpoHyw%40mail.gmail.com.

[Michael Karlesky]

FYI — The original post did come to me.

On Jul 10, 2024, at 10:26 AM, Mark Vander Voord <mvande...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/throwtheswitch/CAAu8-XEKJ%2Bnp9dkt%3D%2Bwnngda%3DW5-6kf79iz%2BZvnozkC6AgGFQQ%40mail.gmail.com.

[David Good]

Interesting ...

My concern is that if some emails are only going to some members (perhaps just Mark and Michael ?) then there is a lot less opportunity for the group to help generally (and more burden on Mike and Mark for support) , and any users caught in that crack will (rightly !) feel that this group is not very helpful .

Now I understand your previous email about google groups !

--David

To view this discussion on the web visit https://groups.google.com/d/msgid/throwtheswitch/CAEiKP4%2BmKTgOXGjwUbrk0ip%3D9MZ36iBAsZWy%2ByHsVEfrgvJ_Kg%40mail.gmail.com.

[Mark Vander Voord]

David:

Actually, I just did some digging and I see the original poster's message was in my spam folder. Perhaps it is in yours as well? I wonder if (because this forum has had so much spam recently) we are easily tripping the spam filters now?  :(

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/throwtheswitch/CALMFhSxPs8AsGUJReAV6oJi%3DGwZnvc5zwd-9VwGbCTWQHmZZrQ%40mail.gmail.com.

[David Good]

Yep ! It was in the spam folder . I had to do an advanced search to dig it out as a regular search still had it buried .

That's unfortunate , but it's hard to know what to do . Gmail is filtering out tons of actual spam , so I was unaware of how bad the problem had become .

--David

To view this discussion on the web visit https://groups.google.com/d/msgid/throwtheswitch/CAAu8-XEmzHrLyRb1X7O75p2vbXWwyzfq6rjO9EOH9C3%3D%2BR4nmw%40mail.gmail.com.

[Mark Vander Voord]

Me too!

Well, we'll see how well things work now. I have switched to requiring people to ask to be part of this forum to block out the spam bots. I've blocked the spam bots I've noticed. I'll try to stay on top of it and hopefully it will recover.

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/throwtheswitch/CALMFhSwFPRgzMvADZzQy1kVf-zdgH4MUNLgXp02tTeK_pAv6yA%40mail.gmail.com.

[Jafet Montesdeoca]

Hello,

 thank you very much :).

This is the latest version of the code after several attempts. It is possible that at the beginning I started using write32_ExpectAndReturn() instead the cmock version. Trial and error.

 I hope you find out something.

 All the best,

Error message

ceedling test:delay_v1


Test 'test_delay_v1.c'
----------------------
Running test_delay_v1.out...
      0 [main] test_delay_v1.out 1406 cygwin_exception::open_stackdumpfile: Dumping stack trace to test_delay_v1.out.stackdump

ERROR: Test executable "test_delay_v1.out" failed.
> Produced no final test result counts in $stdout:
0 [main] test_delay_v1.out 1406 cygwin_exception::open_stackdumpfile: Dumping stack trace to test_delay_v1.out.stackdump

> And exited with status: [0] (count of failed tests).
> This is often a symptom of a bad memory access in source or test code.

rake aborted!

C:/Ruby30-x64/bin/ceedling:25:in `load'
C:/Ruby30-x64/bin/ceedling:25:in `<main>'
Tasks: TOP => build/test/results/test_delay_v1.pass
(See full trace by running task with --trace)

--------------------
OVERALL TEST SUMMARY
--------------------

No tests executed.

Stackdump

cat test_delay_v1.out.stackdump
Exception: STATUS_ACCESS_VIOLATION at rip=001004055F8
rax=0000000000000008 rbx=000000080004CE30 rcx=0000000000000018
rdx=0000000000000000 rsi=0000000000000020 rdi=000000018026A0B3
r8 =0000000000078000 r9 =0000000000000000 r10=00000000FFFFE458
r11=0000000100000000 r12=00000000FFFFCC50 r13=00000000FFFFCC60
r14=0000000000000001 r15=0000000000000000
rbp=00000000FFFFCB20 rsp=00000000FFFFCAE0
program=C:\Users\JafetMontesdeoca\Documents\Development\Embedded_UT\build\test\out\test_delay_v1.out, pid 1406, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame        Function    Args
000FFFFCB20  001004055F8 (00100402C24, 000FFFFCB70, 0010040212B, 00100407038)
000FFFFCB60  001004019BB (00140F00000, 00100078000, 00000000022, 000FFFFCC50)
000FFFFCBA0  00100401422 (0018026A0B3, 000FFFFCD30, 0080004CE30, 000FFFFCC00)
000FFFFCBD0  001004011B4 (00100407060, 00000000032, 00000000001, 000FFFFCD30)
000FFFFCC00  00100401247 (00180049B21, 000FFFFCC60, 00100000002, 00180322FC0)
000FFFFCD30  00180049B8D (00000000000, 00000000000, 00000000000, 00000000000)
000FFFFFFF0  00180047746 (00000000000, 00000000000, 00000000000, 00000000000)
000FFFFFFF0  001800477F4 (00000000000, 00000000000, 00000000000, 00000000000)
End of stack trace

Versions:

ceedling version
   Ceedling:: 0.31.1
      Unity:: 2.5.4
      CMock:: 2.5.4
 CException:: 1.3.3

[Jafet Montesdeoca]

Hello guys,

 any help, idea or info request??

 All the best,

[Jafet Montesdeoca]

 After setting a docker with ceedling it's working with no problems or more changes than paths.

 Last time developing on windows.

 By the way, thank you very much for the ceedling / unity system.

 Have a nice day.