Reading gstreamer udp-stream from .blf-file fails

[Former user]

Reading a .blf file that includes udp-packets send by gstreamer aborts with ObjectHeaderBase being nullptr.

Same file can be read by vector CANalizer without problems. Other udp packets / ethernet frames are working fine. No difference if other data is present or not (e.g. CAN-Channels).

Attached you will find a .blf log containing the aforementioned udp-stream only.

The issue was reproduces with Versions 2.1.5 and 2.1.6

[Tobias Lorenz]

Hello,

I checked the BLF now in multiple environments and couldn’t reproduce the issue. The vector-blf-parser example successfully decodes 19468 objects of type EthernetFrameEx.

What environment do you use the library in? What compiler and ~options?

Bye Tobias

[Christof Meinert]

Hi Tobias, thanks for the quick reply.

My environment is

GCC 7.4.0 on Ubuntu 18.04 with the flags -O3 -DNDEBUG

The file is part of a catkin compilation (ROS1-Melodic) that is triggered with the following command: catkin_make --directory ${workspaceFolder} -DCMAKE_BUILD_TYPE=Release

‌

Taking a look at the example (Parser.cpp) with the file I send you it does look like this.

FileStatistics:
statisticsSize: 0x90
applicationId: 84
applicationVersion: 245.61.0
apiVersion: 1.1.10.0
fileSize: 27366520 (0x1a19478)
uncompressedFileSize: 29014245 (0x1bab8e5)
objectCount: 20200
objectsRead: 96
measurementStartTime: 2019-10-14 1 18:11:22.563
lastObjectTime: 2019-10-14 1 18:11:52.777
fileSizeWithoutUnknown115: 0x1a192e6

…

ObjectSize=536 doesn't match calculatedObjectSize()=56

End of file.
uncompressedFileSize: 29014245
objectCount: 20200

I guess the objectsRead should be equal to objectCount?

Taking a look at more relevant logs, that I’m not allowed to share, it does look more grim.

FileStatistics:
statisticsSize: 0x90
applicationId: 84
applicationVersion: 245.61.0
apiVersion: 4.6.5.17
fileSize: 2049629000 (0x7a2adb48)
uncompressedFileSize: 10024578740 (0x25582eeb4)
objectCount: 25040292
objectsRead: 0
measurementStartTime: 2019-10-24 4 13:29:30.0
lastObjectTime: 2019-10-24 4 13:38:4.885
fileSizeWithoutUnknown115: 0x7a2ab282

…

ObjectSize=120 doesn't match calculatedObjectSize()=64

End of file.
uncompressedFileSize: 917872
objectCount: 310

‌

I hope I provided all information necessary.

Thanks for your effort and time in this investigation.

[Tobias Lorenz]

Hi Christof,

I can reproduce the issue now. However the data looks different here:

FileStatistics:
  statisticsSize: 0x90
  applicationId: 84
  applicationVersion: 245.61.0
  apiVersion: 1.1.10.0
  fileSize: 27366520 (0x1a19478)
  uncompressedFileSize: 29014245 (0x1bab8e5)
  objectCount: 20200
  objectsRead: 96
  measurementStartTime: 2019-10-14 1 18:11:22.563
  lastObjectTime: 2019-10-14 1 18:11:52.777
  fileSizeWithoutUnknown115: 0x1a192e6

...

30214581000 ns: Unknown115: res[0]=0x30113e80 res[1]=0x000001f0 res[2]=0x3011436a res[3]=0x01e801f0 res[4]=0x00180008 res[5]=0x000003e8
ObjectSize=536 doesn't match calculatedObjectSize()=56

End of file.
uncompressedFileSize: 29014245
objectCount: 20200

So it seems that only the trailing message “Unknown115” has a different format. I’ll check and fix it.

Can you try with the latest version if your objectCount also totals up to 20200?

Bye

Tobias

[Tobias Lorenz]

Hi Christof,

I did a commit in this branch: https://bitbucket.org/tobylorenz/vector_blf/branch/issue-18.

Instead of showing the message “ObjectSize=120 doesn't match calculatedObjectSize()=64” it just consums the available data. The parser has been changed as well to show what’s inside this message.

Unknown115 is anyway the last message, so there isn’t anything important missing, if the library/parser stops here.

Bye

Tobias

[Tobias Lorenz]

Hi,

I merged issue-18 branch into master and released v2.2.0.

I assume this issue is solved now.

Bye Tobias