O3R::Ports() exits with a segfault when a port is not running

[paradoxon82]

Hi ifm community,
I have a setup of 4 cameras connected to the VPU runnig and did some tests with configuration or hardware errors.
Specifically I tried this:

• VPU is configured with 4 camera ports
• I disconnect one
• I reboot the vpu by disconnecting power
• After the reboot the missing port is blinking
• Now I start our application which tries to asses at startup if all ports are connected.
• It calls O3R::Ports() which will causes a core dump with this message:
  terminate called after throwing an instance of 'ifm3d::json_abi_v3_11_2::detail::type_error'

When looking at the configuration via O3R::Get() I found this part about the disconnected port empty:
{ … „ports“: { …. "port3": { "info": { "partNumber": null } },…. } }
So the port information is empty apart from partNumber being null.
I can live with that but I would assume O3R::Ports() should still work and probably return a smaller list of ports, or the full list and report an error somehow.

The software version is v1.3.3

Best Regards,
Daniel

[graugans]

Hej Daniel, What firmware version are you running?
I assume the core dump comes from not catching the exception. I guess you have at some point in time executed a saveInit to permamently store the configuration on the device, maybe by fiddling around with the Vision Assistant. So you have forced the device to expect a head being connected. If there is no Init configuration the device will not care.

Things are getting even a bit trickier when you switch the heads. So what would be your expected behaviour in this case?

[paradoxon82]

I have to check which firmware. But I assume 1.0.14. This was the last update we discussed internally.
There is no exception to catch as far as I can tell. I can check again.
I would suspect the Ports() method not throw at all. It is not documented.
Either it should:

• return the configured number of ports, which would not help me but at least be consistent
• return a reduced number since it seems like the VPU recognized the disconnect

In real world applications a camera can break or become disconnected for multiple reasons.
I just wanted to have a check on startup that gives me the number and position of connected cameras.

Best Regards and Thanks,
Daniel

[inbangsa]

@paradoxon82, can you please provide the code example to reproduce the issue and it will be very helpful if you can provide dump of the device before and after the disconnect of the port.

you can get the dump of the device by ifm3d tool as

ifm3d dump

[paradoxon82]

So, I used Get() instead of ifm3d dump which should return the same? If not I will dump it from the camera next week.
This one is the initial state:
fresh_install_settings.txt
After a reboot (power disconnection), I get this:
fresh_install_settings_restart_after_removal.txt

The code looks like this, where m_camera is a std::shared_ptr<ifm3d::O3R>:

std::cout << "[3D Camera O3R] config on startup:" << std::endl;  
std::cout  << m_camera->Get() << std::endl;
std::vector<ifm3d::PortInfo> ports = m_camera->Ports();
for (const auto& p : ports)
{
    std::cout << "Port: " << p.port << " pcic: " << p.pcic_port << " type: " << p.type << std::endl;
}

The call to Ports() will cause the core dump when called with a disconnected wire after reboot.

[lola-masson]

Hi @paradoxon82,

My guess is that, as @graugans mentioned, this issue comes from a configuration that was persistently saved on the device (save_init() function). This unfortunately happens under the hood when using the ifm3d CLI and some functions of the Vision Assistant. This persistent configuration ensures that the system boots up in the expected state, which means that an error is triggered when the configuration is different from expected, for instance if a camera is unplugged or switched for a different one. The problem is that we currently do not have an easy way to get rid of this persistent configuration, except for performing a factory reset, which also deletes all files and docker containers. What I recommend: check the persistent configuration on your device with the get_init() function. If you have a configuration saved there that is different from your current configuration, delete it with a factory_reset().

We are working on a feature to only erase the persistent configuration and not have to use the factory reset, but until this is released you will have to use the process I just described.

Let us know if the issue persists.

[paradoxon82]

Thank you, good to know about how the reset works.
But my issue is much more basic, and I am not sure if that got thru.
Let me describe a possible case:

• I have a supposed setup for the cameras (let's say 4 cameras, two in the front and two in the back)
• The application works.
• Somebody does some work on a switched off platform and a camera gets disconnected
  • Or the cable breaks
  • Or the camera breaks
• The VPU is restarted
• My application starts
• It checks the connected ports using O3R::Ports()
• Then there is a coredump and no exception for me to handle.

So for me it looks like the O3R::Ports() method parses the current configuration returned by O3R::Get() in a way that does not check correctly if some values exist.
I will now check whatever is returned by O3R::Get() instead of using O3R::Ports()
The whole point of my post is that O3R::Ports() is not safe to use. Whether of a misconfiguration or a hardware defect.

[lola-masson]

Thank you for the clarification. Yes I think you are correct, the Ports() function is not able to handle configurations where a "port" section of the JSON is not filled as expected. I will create a defect for this and we will solve it as soon as possible.

[paradoxon82]

Thank you for the information. I will wait for the update.

[paradoxon82]

Hello,
I just wanted to check in about the progress of this issue

[lola-masson]

Hi @paradoxon82, no updates on this topic yet. We are sprinting on the release of a new firmware so it has taken precedence over other issues. Thanks for your understanding.