TDA4VE-Q1: Differences in Object Descriptor APIs between SDK: 8.0 and 9.2

Hi xftu,

I am not seeing any implementation changes only the function names changed as you mentioned from 8.4 to 9.2 version. obj_desc_cmd is used by nodeSendCommand api check if that is getting freed anywhere by this api ownObjDescFree(), if you are getting obj_desc_id from application A check before exception and after exception as well to ensure that exception is not freeing the obj_desc.

And what was the type present in the structure  you got from ownObjDescGet (obj_desc_i), is it invalid or some type was there ? 

also check for other types of objects whether ownObjDescGet (obj_desc_i) is giving same object type or not.

Regards,
Gokul

hi Gokul S,

Thanks for your reply.

I simulated an exception in application A by directly using the killall command. The application has a signal to handle the kill, but did not perform operations such as ownObjDescFree(). I simply printed some logs and exited (0).
Use ownObjDescGet to obtain objects of type tivx_obj_desc_cmd_t, and the obtained type is 7061; Obtain different types of objects, such as tivx_obj_desc_node_t, and the obtained type is also 7061. The obtained type value is the same for different power on cycles.

Best Regards,

xftu

Hi xftu,

Thank you for sharing info, I will recreate this from my end and get back to you by this week end.

Regards,
Gokul

Hi xftu,

I have tested it from my side and I could able to get the obj_desc from other process using ownObjDescGet() api even after killing the other process, and also verified the type (in both cases it is same)

Meanwhile have you modified anything in the tiovx framework ?

7061 is not matching with any of the tivx_obj_desc_type_e enum.

can you check obj_desc allocated in the application by printing it and then get the same obj_desc in other process.

Regards,
Gokul

Hi Gokul S,

I have updated some of the code for the tiovx framework, but only added or updated some log printing.

I printed all the assigned obj_desc on ownObjDescAlloc, and the following 4 are the IDs of the obj_desc I used.

I printed obj_desc, and indeed the result on my end is different from the one you reproduced.

Also, let me describe the key steps of my operation here. Can you help me check if there are any improper operations.

I printed the information of obj_desc before sending it to application A, as follows:

Then I kill app A, and when app B detects that app A is not in the process space, it will perform the following tiovx operations:

Then I printed the information of obj_desc in application B, as shown below:

Best Regards,

xftu

Hi xftu,

You are calling tivxInit() in app B, just want to confirm app B is a normal or openvx app, if it is openvx app then you could have called appInit() at the beginning , then no need to call tivxInit() again.

Can you try calling appInit() instead of calling,

Regards,
Gokul

Hi Gokul S,

App B is a Linux application of J721S2. It seems that the Vision app does not implement the appInit interface. Do you want me to use the Vision app interface? Do I have a misunderstanding? If so, could you please tell me which library's interface it is.

Best Regards,

xftu

Hi xftu,

I need to understand that when are you calling the api's 

is it after process A has been killed or during the application startup of the app B ?

xf t said:

It seems that the Vision app does not implement the appInit interface. Do you want me to use the Vision app interface? Do I have a misunderstanding? If so, could you please tell me which library's interface it is

I was saying about the appInit()

that is called at beginning of every openvx application, if you see any demo application in the sdk it starts with this api. it is defined in vision_apps/utils/app_init/src/app_init.c

Regards,
Gokul

Hi Gokul S,

These apis are called after process A has been killed.

Adding the tivxHostInit interface call on top of the current one will have the same effect as calling appInit. I will try it later.

Best Regards,

xftu

Hi Gokul S,

I tried to add the tivxHostInit call to the previous call, but it did not solve the problem.

Best Regards,

xftu

Hi xftu,

can you comment out the appIpcRegisterNotifyHandler() and check, this api is called inside tivxInit() and it registers objdescipchadler that is used by framework.

How can I reproduce this from my side ? When I tried I killed process A (ctrl +c ) and after that opened process B and printed the object descriptors allocated by process A and verified the types, it is matching with what process A has printed.

can you also try this appInit() calls in app B in beginning or before killing app A.

Regards,
Gokul

Hi Gokul S,

Gokul S said:

How can I reproduce this from my side ? When I tried I killed process A (ctrl +c ) and after that opened process B and printed the object descriptors allocated by process A and verified the types, it is matching with what process A has printed.

I will describe the key points of the application scenario and see if you can reproduce this accordingly. 
1. APP A and APP B are both Linux applications that run in the background;
2. APP B is launched first, and APP A is pulled up through fork and execlp. At this time, APP B has not initialized any tiovx resources;
3. APP A is an application of tiovx. After normal initialization of tiovx, the object descriptors generated by APP A can be synchronized with APP B;
4. Ensure that APP B receives object descriptors, and then use the killall command to kill APP A;
5. After confirming that app A has been killed, app B calls the following tiovx interface and  then checks if the object descriptors are valid.

I will follow your suggestions to troubleshoot the problem simultaneously.

Best Regards,

xftu

Hi Gokul S,

Gokul S said:

can you comment out the appIpcRegisterNotifyHandler() and check, this api is called inside tivxInit() and it registers objdescipchadler that is used by framework.

According to the above suggestion, the printing of information for these 4 object descriptors will be changed as follows:

Gokul S said:

can you also try this appInit() calls in app B in beginning or before killing app A.

Then, based on the first suggestion, make changes according to the second suggestion, and the printed content will be modified as follows:

None of the types are correct.

Best Regards,

xftu

Hi xftu,

Can you share the test setup and code to reproduce this from our side.

xf t said:

I will describe the key points of the application scenario and see if you can reproduce this accordingly. 

It will be time consuming and might take some time for me to recreate this exact scenario, so If possible can you create some test code so that i can test.

Regards,
Gokul

Hi Gokul S,

The entire project involves a lot of code, and I will try to extract this part and write a new demo, which will take some time. I will share with you any progress made.

Best Regards,

xftu

Hi xftu,

Thank you, I will be waiting for you demo code to test it from my side.

Regards,
Gokul

Hi Gokul S,

We found that there was an error in the memory mapping of the app, and the problem has been resolved. Thank you for your support.

Best Regards,

xftu

Thank you for the confirmation, closing this thread

Regards,
Gokul