Closed chrisruk closed 2 years ago
I'm suspicious that this may actually be a libcamera bug. The 2nd instance realises that it can't lock all the media devices, and therefore decides to unlock them all again and give up: here.
Only that very call to unlock()
causes it to try to re-acquire the mutex (lock_
) that it already has, causing it to hang. Not sure what the best fix is there... give up lock_
first? have a version of unlock()
that doesn't re-take the lock? make lock_
itself a re-entrant kind of a mutex?
@kbingham Does this sound right? Any thoughts on the best course of action?
Could you try testing with this patch please? https://patchwork.libcamera.org/patch/16728/
It sounds like something I reported on IPU3 recently, and Laurent posted that as a fix.
Ah yes, that does indeed fix it for me! I see the "unlocking" bit that happens when it fails is now removed from being under the mutex.
So what's the ETA for this one...? Thanks!!
Could you reply to the patch saying it fixes an issue for you please? (+RB/TB tags :D)
It fixes the IPU3 for me - but breaks CTS (chrome camera test suite) because now it lets two cameras run, and that breaks - but that's not /your/ problem. So I'm holding up the patch ... but if it solves a problem for you we should look to merge it.
@kbingham Fabulous, thank you!
I'm going to close this one as it will go away when we pick up the latest libcamera for our next release. Thanks everyone!
Describe the bug
If you run two interpreters both with: p = Picamera2()
The second interpreter will hang on this call.
Expected behaviour
An exception should be produced in the second call to picamera2.
See also #223