Access violation when writing a CanFdMessage64

[Former user]

I get an access violation exception, when a canfd message shall be written. Example:

    auto * canMessage = new Vector::BLF::CanFdMessage64;
    canMessage->channel = 1;
    canMessage->dlc = 9;
    canMessage->id = 0x33;
    canMessage->data[0] = 0x44;
    canMessage->data[1] = 0x55;
    canMessage->data[2] = 0x55;
    canMessage->data[3] = 0x55;
    canMessage->data[4] = 0x55;
    canMessage->data[5] = 0x55;
    canMessage->data[6] = 0x55;
    canMessage->data[7] = 0x55;
    canMessage->data[8] = 0x55;
    canMessage->data[9] = 0x55;
    canMessage->data[10] = 0x55;
    canMessage->data[11] = 0x55;
    file.write(canMessage);

Exception 0xc0000005 encountered at address 0x7ff7b44f13ee: Access violation writing location 0x00000000

[Tobias Lorenz]

I try to reproduce it here by adding a uni test with the instructions provided.

[Tobias Lorenz]

Found the issue in the provided code:

You need to reserve/resize the vector before accessing it. So there is just a canMessage->resize(12); missing in your code.

Can happen

[Tobias Lorenz]

Found the issue in the provided code. No need to change anything in the library.

[Daniel Prokhorov]

Thanks for the quick response! I’m more of a .NET and C# developer rather then C++, so sorry for my inexperience with the latter language .

I’ve tried this now with the resize code and I’ve discovered the following:

So, the rest of the data is missing when opening the .blf file in Vector CANoe. My test code:

‌

uint32_t GetDataLenFromDlc(uint32_t dlc)
{
    switch (dlc) {
        case 9:{
            return 12;
        }
        case 10:{
            return 16;
        }
        case 11:{
            return 20;
        }
        case 12:{
            return 24;
        }
        case 13:{
            return 32;
        }
        case 14:{
            return 48;
        }
        case 15:{
            return 64;
        }
        default:{
            return dlc;
        }
    }
}

int main(int argc, char * argv[]) {
    if (argc != 2) {
        std::cout << "Write-Example <filename.blf>" << std::endl;
        return -1;
    }

    /* open file for writing */
    Vector::BLF::File file;
    file.open(argv[1], std::ios_base::out);
    if (!file.is_open()) {
        std::cout << "Unable to open file" << std::endl;
        return -1;
    }

    /* write a CanMessage */
    auto * canMessage = new Vector::BLF::CanFdMessage64;
    canMessage->channel = 1;
    canMessage->dlc = 9;
    canMessage->id = 0x33;
    canMessage->dir = 1;

    uint8_t* data = new uint8_t[] {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12};

    uint32_t data_length = GetDataLenFromDlc(canMessage->dlc);

    canMessage->data.resize(data_length);

    for (uint32_t i = 0; i < data_length; ++i) {
        canMessage->data[i] = data[i];
    }

    file.write(canMessage);

    /* close file */
    file.close();

    return 0;
}

Then there is one more strange thing to be mentioned here. So, when I run the code with the

set(CMAKE_BUILD_TYPE Debug)

rather then Release, I get this error when I try to debug in the CLion IDE:

Exception 0xc0000005 encountered at address 0x7ffdcf8712de: Access violation reading location 0x00000000

When I hit the run button, I get this error:

Process finished with exit code -1073741819 (0xC0000005)

I have no idea, why this behaves so differently.

[Tobias Lorenz]

CANoe only shows 8 data bytes, because it thinks, it’s a normal CAN frame. The CanFdMessage64 can be used to store normal CAN frames and CANFD frames. If it’s CANFD, then in flags the bit 12 (Extended Data Length) need to be set.

I’m not sure about the exception that CLion shows. I use gcc/gdb environment. Can you provide more information to debug this issue?

[Daniel Prokhorov]

Your’re right. Setting the flags does the trick: canMessage->flags = 0x1000;

Concerning CLion, I have no idea what kind of information will be usefull for you. Currently, it looks like this:

‌

[Tobias Lorenz]

I pushed a change into master that contains your code as test code. Also there are some slight changes to CanFdMessages that I took over from another branch. And also, this might fix the exception you see, I pushed a change that cleans write queues on file closure.