GNOME Bugzilla – Bug 726586
OpenNI2 plugin doesn't initialize correctly
Last modified: 2016-12-31 10:09:06 UTC
There are three issues with initialization in the OpenNI2 plugin: - The OpenNI objects are never actually constructed, which leaves them in an invalid state. I assume it worked for the original author, but this breaks completely on my ARM machine and results in seemingly-impossible initialization errors. - If the OpenNI device fails to initialize, the plugin correctly returns an empty list of capabilities, but it doesn't unlock the Gst object. This results in a deadlock that prevents the user from seeing any useful error messages. - If the user doesn't specify a device URI, the plugin correctly uses openni::ANY_DEVICE to grab the first available device, but the case is needlessly disallowed in two code paths. I've attached a patch that resolves these for review.
Created attachment 272211 [details] [review] Patch that resolves the initialization issues
Andrew, thanks for tackling this! Pending slomo@ review, this all sounds reasonable to me. Interesting the different OpenNI allocation behaviour in your platform.
Review of attachment 272211 [details] [review]: Please attach this as "git format-patch" style patch ::: ext/openni2/gstopenni2src.cpp @@ +185,3 @@ + new((void*)&ni2src->colorVideoMode) openni::VideoMode(); + new((void*)&ni2src->depthFrame) openni::VideoFrameRef(); + new((void*)&ni2src->colorFrame) openni::VideoFrameRef(); Please store pointers in the struct and then use ni2src->device = new openni::Device(); etc. Also delete them in gst_openni2_src_finalize().
Created attachment 275847 [details] [review] revised patch
Thanks for the patch, and sorry it took so long to get to it. Looks like this was fixed independently also in bug #732535 (the object init and unlock at least, not sure about the 'any device' bits). *** This bug has been marked as a duplicate of bug 732535 ***