Conflict between JavaCV 1.5.7-snapshot and Depthai-2.13.3-1.5.7-snapshot #1118
Comments
|
It might be your video driver not supporting OpenGL properly. Make sure OpenGL support in Java 2D is disabled.
|
|
Also, if you don't need to use Java 2D, I would recommend using JavaFX instead: |
|
Moreover, DepthAI 2.14.0 has been released and the presets upgraded in commit 9dd400b, so you might want to try that as well. |
|
Just tried DepthAI 2.14.0 and added below property to still not work. |
|
Does it do anything different if you set the "org.bytedeco.javacpp.nopointergc" system property to "true"? |
|
Also, try to set the "org.bytedeco.javacpp.logger.debug" system property to "true", and let me know what you get on the console. I might be able to see something going wrong there from that log. |
|
OK. After I add The weird thing is that, if I change the initialization of JavaCanvas to front of Original code: After changed: Debug messages aftere code changed |
That pops up just before the crash, so this pointer is probably getting deallocated prematurely. Make sure that doesn't happen. |
|
Any solution or workaround to this? I experience a similar issue on OSX and Ubuntu using version 1.5.7. Grabbing stops after some minutes at
with this log: |
|
@ecmnet Please try to set the "org.bytedeco.javacpp.nopointergc" system property to "true" and see if that helps. |
|
@saudet Unfortunately not - I see that in this case neither registering nor GC takes place. Python and C++ DepthAI examples work.
|
|
Ok, thanks for testing. If DepthAI uses signal handlers, you'll need to do some signal chaining: |
|
@saudet I tried using the -Xrs option as well as the environment variable settings as described in the document above. Both with no success. |
|
It's possible DepthAI becomes unstable when we don't immediately release all memory that it returns to us. For example, make sure |
|
@saudet Tried that also in different ways - even doing it step by step closing all objects immediately does not work.
|
|
An additional observation: Grabbing lives longer (up to 3 mins), when closing each object immediately and using PointerScope enclosing all statements. |
|
If you still see "Collecting" with an address other than 0 in the log, that means it's not getting deallocated explicitly. Find where they come from, or use additional PointerScope blocks, and make sure to close them as quickly as possible. |
|
Weird. Meanwhile I use a callback to grab the frames, which seems to work as long as I do not have an AnimationTimer (to update the Java FXImage) - I even copied the grabbed array - but as soon as I enable the timer, grabbing stops: |
|
DepthAI may not be entirely thread-safe, don't try to make calls from multiple threads.
|
|
It does register some signal handlers for use with Backward - crash stack printer. Ps: |
|
@saudet @themarpe Seems to work now by
So I assume, there were two root causes: Threading and signal-handling. Thanks a lot for your support. |
|
@saudet: While this is working now properly with OSX, I receive now the issue as described by @wureka with Ubuntu. Obviously still a deallocation issue there. |
|
Right, you'll probably need to get rid of those "Collecting" lines. You could set the "org.bytedeco.javacpp.nopointergc" system property, but as discussed above, that would likely result in memory leaks, and could also make DepthAI unstable. You'll need to figure out where those objects are and close them as soon as they are not needed anymore, or try to use PointerScope blocks as necessary. |
|
@saudet, @themarpe After cleaning up, the crash did not appear anymore in the context of 'Collecting'. But still it does not work. It happens (after a couple of seconds) as soon as I place
into the code - no other DepthAI-related code is involved (even no 'device'). Closing it soon or surrounding it by PointerScope does not help. The object mentioned in the dump does not appear in the java context at all. Note, that this is Ubuntu only - OSX runs fine. |
|
Maybe we need to make sure the Pipeline stays alive? Try to close at a later point in time. |
|
No chance - I got it working slightly longer (about 800 frames), but all cases ended with a crash. |
|
With signal handler and backward disabled, everything on a signal thread? That reminds me, the JDK doesn't run the main thread on the first thread of the process. It is possible DepthAI doesn't like that. |
|
@saudet @themarpe After carefully redesigning the code, using blocking queues, etc, I managed to get DepthAI running on Ubuntu for a couple of minutes, but far from stable. The same code runs smoothly for hours on OSX. However, I saw a multihreading-related branch on DepthAI side - maybe that helps in future. Currently I consider DepthAI not usable on Ubuntu with Java. |
|
@Grumpy141 @ecmnet @wureka |
|
This fixed my issue. 2.14.1 is stable now, both on Mac O/S and Linux armhf
I didn't have to set the environment variable.
On Wednesday, February 16, 2022, 05:46:55 PM MST, Samuel Audet ***@***.***> wrote:
@Grumpy141 @ecmnet @wureka
I've disabled the signal handlers in commit 5ac61a8, please give it a try with the snapshots:
https://oss.sonatype.org/content/repositories/snapshots/org/bytedeco/depthai/2.14.1-1.5.8-SNAPSHOT/
Just to be extra sure DepthAI doesn't try to install them anyway, please also make sure to set the "DEPTHAI_INSTALL_SIGNAL_HANDLER" environment variable to "0".
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Thanks alot @saudet! |
|
The workaround has been released with version 1.5.8. Thank you all for reporting and for testing! Enjoy |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment:
Test code:
It seems that JavaCV has something conflicts with Depthai in this version. But this did not happen in the old version (JavaCV 1.5.5 vs Depthai 2.5.x, 2.6.x)
If I use
imshowof opencv to show the grabbed images from OAK-D camera, everything is fine.However, if I use
CanvasFrameof JavaCV to show the grabbed image, below errors will happen:The above error happens on below line (line 73 in Demo.java in test code):
If test only JavaCV without involving depthai, JavaCV works fine.
The text was updated successfully, but these errors were encountered: