-
Notifications
You must be signed in to change notification settings - Fork 473
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Potential memory leak if camera is being moved #678
Comments
Hi @rs1659 , As a temporary workaround, you can try disabling and re-enabling the positional tracking every few hours to free up memory. I'm not sure if this approach will be a viable long-term solution for you. Additionally, it seems from your image that you are using GEN_1 positional tracking. Since this version, we have released two other positional tracking modes: GEN_2 and the latest, GEN_3, which is available in our most recent EA release. These newer modes offer improved accuracy and a lower memory footprint related to loop closure, especially GEN_3. Please feel free to reach out if you have any questions. Regards, |
Hello @TanguyHardelin , thanks alot for taking the time to investigate and answer. To address your points:
Additionally, you mention the disabling and re-enabling as a "temporary" workaround. Is there anything in the works which addresses this permanently? If you have any further ideas, I'd be very grateful to hear them but I will continue investigating the root cause in the meantime even though it is extremely time-consuming due to each reproduction consuming upwards of 30 minutes. |
Preliminary Checks
Description
We have a project in our company where we use multiple Zed 2i cameras (currently four, one in each direction for a 360° coverage) mounted to a movable machine and connected to a Jetson AGX Orin in order to detect people coming close to the machine. For this, we have a custom software written in C++ which utilizes the Zed SDK and the provided sample code to interact with the cameras. Now for the tricky part:
We noticed that after some runtime, our software always closed without any reasons given. On further inspection (checking the log of the OS itself), the application process is being killed by the operating system due to running out of system memory and upon further inspection, our application actually managed to fill the 64 GB RAM of the Jetson in about 1-2 days of runtime.
To figure out the problem, we took the setup to the office and let it run here for a while without any noticeable problems even after letting it run for multiple days. The only way to produce the issue seemed to be to move the camera(s) in a way, which brings a person in and out of view of the camera, which resulted in a steady increase in consumed memory.
To provide some further details, I executed the software with Heaptrack attached, which may give some helpful information.
First the heap memory consumption over time:
I moved the camera directly after the startup but as can be noticed from the process memory usage and also in the graph, the memory leak always needs some "spin up" time to get going, then the increase rate seems quite constant, albeit rapid.
The trace also seems quite interesting:
This high memory usage from "fastAMalloc" (and onwards) can only be observed if the camera is moved as described above.
Since the trace here mentions methods which are apparently contained within the sdk of this repo, I think bringing the issue up here is a good starting point.
If you need any further information or have any suggestions, please feel free to ask/tell me, as this is quite an urgent topic for us at the moment.
Steps to Reproduce
Expected Result
Application should perform as normal like it is the case if cameras are not being moved.
Actual Result
Application quickly consumes a massive amount of system memory, leading to the process being killed by the OS.
ZED Camera model
ZED2i
Environment
Anything else?
No response
The text was updated successfully, but these errors were encountered: