covesa / vehicle_signal_interface Goto Github PK

Hello，

I read the document README.md.api but after I open the source files, seems the document not match with source. eg vsi_fire_signal in document but not in source.

Is this project still under development?

• I have cloned the master branch of vehicle_signal_interface. During the build i faced following issue

user@toad:~/project/vehicle_signal_interface$ make
---> Building in /home/rengaraj/project/vehicle_signal_interface/core ...
Compiling vsi_core_api.c
In file included from sharedMemory.h:50:0,
                 from vsi_core_api.h:21,
                 from vsi_core_api.c:27:
sharedMemoryLocks.h:23:19: fatal error: trace.h: No such file or directory
 #include "trace.h"
                   ^
compilation terminated.
Makefile:195: recipe for target 'vsi_core_api.o' failed
make[1]: *** [vsi_core_api.o] Error 1
<--- ...Finished building in /home/rengaraj/project/vehicle_signal_interface/core
---> Building in /home/rengaraj/project/vehicle_signal_interface/api ...
Rebuilding the VSI library...
In file included from ../core/sharedMemory.h:50:0,
                 from ../core/vsi_core_api.h:21,
                 from vsi.h:32,
                 from vsi.c:28:
../core/sharedMemoryLocks.h:23:19: fatal error: trace.h: No such file or directory
 #include "trace.h"
                   ^
compilation terminated.
Makefile:103: recipe for target 'libvsi.so' failed
make[1]: *** [libvsi.so] Error 1
<--- ...Finished building in /home/rengaraj/project/vehicle_signal_interface/api

• I don't find trace.c and trace.h file present inside the source.

There should be separate include folder, so it's clear which header should be used/deployed on the system for development.

Meanwhile, could you please clarify which headers are development headers and should be packaged in -dev package.

Thank you.

It should not be possible to add a signal to a group multiple times. All signal/group combinations should be unique.

We are unable to fire signals by name, or get the key associated with a name. Root cause is most likely the comparision vsi makes between keys, which compares adresses and not values. Thus trying to compare the name vsi has loaded from file and added to data storage, with a name we send from 'outside' the adresses would be different, and thus fail the lookup. But if we first get the name associated with a key, and then use this data in the fire by name we are successful.

Reproducable with available sample program, fails when trying to fire 'bar' and other signals by name.

The function vsi_define_signal_name() in vsi.c in incorrectly copying the string. strncpy() does not null terminate. Happy to create a PR for this.

diff --git a/api/vsi.c b/api/vsi.c
index e146f82..1a44c61 100644
--- a/api/vsi.c
+++ b/api/vsi.c
@@ -2141,8 +2141,8 @@ int vsi_define_signal_name ( vsi_handle handle,
// TODO: Check for string overflow here!
//
nameIdDefinition->name = sm_malloc ( strlen(name) + 1 );

• strncpy ( nameIdDefinition->name, name, strlen(name) );
• nameIdDefinition->name[strlen(name)+1] = 0;

• nameIdDefinition->name[0] = '\0';

• strncat(nameIdDefinition->name, name, strlen(name) + 1);

  //
  // Go insert the new id/name definition structure into both of the btree

sample.c works fine with vss_rel_1.vsi, blows up at signal count 88 with vss_rel_1.vsi.FULL

btree_compare_function() at btree.c:4,074 0x7ffff7600419
btree btree_t * 0x604418
data1 void * 0x7ffff71e2188
data2 void * 0x8002b71dd000
i unsigned int 0
status int 0
index int 0
ptr1 offset_t * 0x7ffff71e2188
ptr2 offset_t * 0x8002b71dd000

btree_insert_nonfull() at btree.c:1,176 0x7ffff75fd0cf
btree_insert() at btree.c:1,293 0x7ffff75fd347
vsi_define_signal_name() at vsi.c:2,154 0x7ffff780b0ed
vsi_VSS_import() at vsi.c:369 0x7ffff78094ee

id	signal_t	926	
privateId	signal_t	0	
tokenCount	int	2	
signalCount	int	88	

vsi_initialize() at vsi.c:251 0x7ffff78092d8
main() at sample.c:103 0x400fed

The filename/path to the vsi file is hardcoded in vsi.h and used when initializing. It would be prefered for us to be able to give this as a parameter instead, or remove the call to vss import inside the initialize function and use a direct call to vss import.

As vsi isn't able to find the vsi file, it prints an error.

When defining new signals with vsi.c::vsi_define_signal_name the termination is not complete and results in garbage characters being present.

Reproducable with the available sample program and small sample vsi file, garbage shown in print of contents at start of sample program.

We are unable to write and read the correct data with the vsi api. When writing a value the data doesn't show up correctly when reading it back, and dumping all data available in the shared memory with the core/tests/dump, but using the writeRecord/readRecord we are able to see it correctly.

Cause found to be in vsi.c::vsi_fire_signal, it takes a result struct wich contains a char* data, but then uses a reference to this pointer when it calls the core function to add the value, causing it to use wrong data.

Reproducable with the available sample program.

When trying to load the vss_rel_1.vsi.FULL file we receive a segmentation fault. We haven't been able to find the root cause, but the error occurs in the btree.c::btree_compare_function. Cause unknown, we haven't found a specific signal or number of signals causing this, all from 86 signals to 250 and above.

Reproducable with the available sample program and sample vsi files.

When trying to use vsi withing a qt application the compiler is crying about a collision of definitions between vsi and qt. This is solved by reordering the import of .h files, and is caused by the btree_t signals on row 402 in sharedMemory.h.

Could be a point to add in documentation.

Hello,

I got that kind message due to loop variable declarations in "for" statement.

btree.c: In function ‘merge_siblings’:
btree.c:1554:9: error: ‘for’ loop initial declarations are only allowed in C99 mode
btree.c:1554:9: note: use option -std=c99 or -std=gnu99 to compile your code

Example:

    newParent = cvtToOffset ( btree, leftChild );
    for ( int i = 0; i <= rightChild->keysInUse; ++i )
    {
        getChildPtr ( btree, rightChild, i )->parent = newParent;
    }

I need to remove these errors and can commit on afterward.
If it makes sense, what should be your preferred data definition ?

int i or int iLoop ? --> it will be at the beginning if the function
sometimes "unsigned int" is used, do we need to keep them ?

Best regards