Question CANFdMessage and CANFDMessage64

[Former user]

Hello,

if I run your test test_CanFDMessage.cpp and CanFDMessage64.cpp I can not see any data!

If I try to add data to a CanFdMessage or CanFdMessage64 with following Code:

auto *msg = new Vector::BLF::CanFdMessage64; int len = 64; for(int i = 0; i < len ;i++) { msg->data.push_back((uint8_t)i); }

I get a write access viloation

I am wrong or is it a bug?

[Tobias Lorenz]

Hello,

what data do you expect to see? When the tests run successfully, you only get the message “*** No errors detected”. Is the output different if you run any of the other tests?

Without haven’t tested it, but data is a normal std::vector, which can be extended using data.push_back, in the way you implemented it. I’m wondering why it results in an access violation…

Can you provide more info?

Bye Tobias

[Thorsten Zarske]

I tested with your Code: src\Vector\BLF\docs\examples\Parser.cpp

read the file: src\Vector\BLF\tests\unittests\events_from_binlog\test_CanFdErrorFrame64.blf

If I run the Code in the Parser.cpp I don’t see any “data” printed in the out console either in the Debugger!

Thanks for your fast Response!

Bye Thorsten

[Tobias Lorenz]

Hi Thorsten,

if I run the parser on the file it looks like this:

$ vector-blf-parser src/Vector/BLF/tests/unittests/events_from_binlog/test_CanFdErrorFrame64.blf 
FileStatistics:
  statisticsSize: 0x90
  applicationId: 212
  applicationVersion: 26.62.0
  apiVersion: 0.0.0.0
  fileSize: 628 (0x274)
  uncompressedFileSize: 628 (0x274)
  objectCount: 2
  objectsRead: 0
  measurementStartTime: 0-0-0 0 0:0:0.0
  lastObjectTime: 0-0-0 0 0:0:0.0
  fileSizeWithoutUnknown115: 0x1e0

2459565876494606882 ns: CanFdErrorFrame64: channel= dlc=34 validDataBytes=64 ecc=68 flags=0x5555 errorCodeExt=0x6666 extFlags=0x7777 extDataOffset=140 id=2863311530 frameLength=3149642683 btrCfgArb=3435973836 btrCfgData=3722304989 timeOffsetBrsNs=4008636142 timeOffsetCrcDelNs=4294967295 crc=0x11111111 errorPosition=8738 data=[00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f]
2459565876494606882 ns: CanFdErrorFrame64: channel= dlc=34 validDataBytes=64 ecc=68 flags=0x5555 errorCodeExt=0x6666 extFlags=0x7777 extDataOffset=140 id=2863311530 frameLength=3149642683 btrCfgArb=3435973836 btrCfgData=3722304989 timeOffsetBrsNs=4008636142 timeOffsetCrcDelNs=4294967295 crc=0x11111111 errorPosition=8738 data=[00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f]
2459565876494606882 ns: Unknown115: res[0]=0xcccccccc res[1]=0xcccccccc res[2]=0xcccccccc res[3]=0x0008cccc res[4]=0x00180008 res[5]=0x000003e8
2459565876494606882 ns: Unknown115: res[0]=0xcccccccc res[1]=0xcccccccc res[2]=0xcccccccc res[3]=0x000ccccc res[4]=0x0000000c res[5]=0x00000000
ObjectSize=60 doesn't match calculatedObjectSize()=56

End of file.
uncompressedFileSize: 628
objectCount: 2

This makes me wonder what is different in your setup. I currently test only on Intel/AMD x64 architecture.

Can you provide more information on your target?

Bye

Tobias

[Tristan VOIRON]

Hello Tobias,

I encountered the same write access violation while trying to add data to a CanFdMessage or CanFdMessage64. I tried to find the reason since like you said data is a normal std::vector. And it appears that when you create the object the vector is not empty but initialised with a capacity inferior to 0 and different values. I hope those infos can help you and if you have any question don’t hesitate.

Best,

Tristan

[Tobias Lorenz]

Hi Tristan,

I’m currently working in issue #21 on a similar issue. Maybe the cause is the same. Would like to test the fix I’ve done in branch fix-issue-21?

Bye Tobias

[Tristan VOIRON]

Hi,

I just tested with the fix done in branch fix-issue-21 but it doesn’t fix it, I still got the write access violation and the vector is still initialized with weird values.

Best, Tristan

[Tristan VOIRON]

Hi Tobias,

Do you have any news on the issue of write access violation while adding data to a CanFdMessage64?

Best, Tristan

[Tobias Lorenz]

Hi Tristan,
Hi Thorsten,

I’ll check it today. Up to now I was not able to reproduce it here. But I’ll dig a little deeper.

Best regards, Tobias

[Tristan VOIRON]

Hi Tobias,

I wanted to help you by sending some code that will enable you to reproduce it, I should have done it before it’s my bad for that. But anyway, I pulled your last update which if I’m not wrong have the fix for the issue 21. And as I wanted to reproduce the issue of write access, I didn’t encounter it again so it seems to be fixed. I will try it again during the day to be sure, but I wanted to tell it to you so that you don’t stay on a problem which is fixed.

So I will return to you later in the day to tell you if everything is okay.

Best regards, Tristan

[Tobias Lorenz]

Hi Tristan,

I added the following test:

BOOST_AUTO_TEST_CASE(Issue20) {
    auto *msg = new Vector::BLF::CanFdMessage64;
    int len = 64;
    for(uint8_t i = 0; i < len; i++) {
        msg->data.push_back(i);
    }
}

But this runs flawless here.

CanFdMessage64::data is just defined and initialized like this:

std::vector<uint8_t> data {};

If there are any errors with this statement, then I can only imagine this to be on the compiler side…

You can try to change the initialization, so remove “{}” and initialize it via the CanFdMessage64 constructor, so one line addition: “data()”.

The only see I see wrong with the line is that the type should be changed to:

std::vector<BYTE> data {};

Bye

Tobias

[Tobias Lorenz]

Hi Tristan,

we just wrote our message in parallel

So, this is good news. Then the problem is not directly to write in the data vector, but it’s likely the problem that was fixed in issue 21. Yes, if you can try again, this would be great.

Thanks,

Tobias

[Tristan VOIRON]

Hi,

Haha indeed we were writing at the same time

Yes this is truly good news, thanks for everything. I will try it and come back.

Tristan

[Tristan VOIRON]

Hi Tobias,

I tested it again during the day and it’s still working so I think the problem was indeed fix.

Thanks again, have a nice day,

Tristan

[Tobias Lorenz]

Great. Thanks for the feedback.

Bye Tobias