UtilPipeline crashes the application when the camera is not connected

UtilPipeline crashes the application when the camera is not connected

If the camera is not connected to the system when the perceptual-computing-powered application starts, the UtilPipeline class will cause the application to crash when its "LoopFrames" method is invoked.....

I have added quite some safety checking code to prevent this to happen, but it turned out that the "IsDisconnected" method of UtilPipeline class always returns false regardless if the camera is connected or not. Because of that, the application think that the camera is there and invoke the processing loop subsequently, which would lead to the same crash.

I am not sure if I am missing something here, but so far, I haven't found any other related method in the UtilPipeline class that deliver the Camera availability nor any discussion topic in the dev forum. Alternatively, I realize that I could probably use the lower-level method like the locateStream to verify the connectivity, but I would really like to verify this issue as it seems like a bug somehow. 

While referring back to the SDK-core manual, below is the snippet describing the UtilPipeline::IsDisconnected method...  seems like the return state logic is opposite to that of the method name somehow..... or?

bool IsDisconnected(void);

Description
This IsDisconnected function returns the input device connection status.

Return Status
true The input device is connected.
false The input device is disconnected.

In any case, from my tests, regardless of the actual physical connectivity of the camera, this method always returns false no matter what...
Has anyone experienced this too?

cheers

SMing

14 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I agree with you that the logic for isDisconnected seems backwards and flawed. I've seen at least one other method in the SDK that behaved similarly but I believe that was corrected in beta 3 and can't remember the command at the moment.  In either case I think Intel should revise it in the next SDK update to match the style of the other methods and so the return values make more sense, such as by renaming it to IsConnected (like IsImageFrame, IsAudioFrame, etc.)

As far as the bigger issue of it always returning false, I have not used that command personally. Instead, I check the Init method of the PXCUPipeline session and if it is null then I set an error flag to true to display a custom warning rather than just crashing. I check once again on the AcquireFrame method in the app loop, and if that is null something went wrong or the camera is disconnected and I show the error.

In Processing my code is arranged something like:

  // Initialize Intel Gesture pipeline

  PXCUPipeline session;
  session = new PXCUPipeline(this);

  // Attempt to initialize gesture sensor, or flag as error
  if (!session.Init(PXCUPipeline.GESTURE)) {
    hasError = true;
    return;
  }

  // Later on, in main loop

  // Can't get frame, break from function
  if (!session.AcquireFrame(true) || hasError)
  {

    // Show custom error message or alert here...
  }
  else
  {

    // Handle gesture functionality here...

  }

I haven't experimented much outside of Processing, however.

I believe the crash issue and the documentation error are fixed in the recent release, or at least I cannot reproduce.

The IsDisconnected method is primarily used to deal with camera disconnection and reconnection cases. The function is effective when streaming is ongoing. It does not work before Init. Yes, the name is a bit odd. We will improve it in the next update.

 

Hi guys,

@ Matthew

Thanks for your kind feedback and sharing. Looks like I should use the lower-level approach instead of the convenient method to get that right for the moment.

Well, as the conveninet method call that I am using right now: UtilPipeline::LoopFrames encapsulates and hides a series of calls under the hood: Init-AcquireFrame-ReleaseFrame-Close. Some of the important error messages might have been ignored in the current SDK version within that conveninet loop, which leads to that crash. Hope that Intel can take a look in this and tune it for the next beta.

@ XinTian

I am using Beta 3 right now, is your recent release refering to this one?
Ok, if the "IsDisconnected" method is designed to work only when the loop is active, then it explains well why I kept receiving "False" before invoking the processing loop with "LoopFrames".

Looks like I should take the "manual" approach to call the "Init-AcquireFrame-ReleaseFrame-Close" sequence explicitly instead of using LoopFrames directly for the timebeing

Thanks again.

Setup: Windows 8 Pro 64-bit, PC SDK Beta 3

cheers
SMing

Hi

I just took a debugger snapshot of the crash when the UtilPipeline::LoopFrames is invoked without the camera. Looking at the call-stack, it turned out that the crash actually happened deep inside the Init method call within the LoopFrames call.  (please refer to the attached screenshot).

By the way, is there any channel to file a bug entry directly to Intel officially? Please advise, thanks!

Setup: Windows 8 Pro 64-bit, PC SDK Beta 3

cheers
SMing

Attachments: 

AttachmentSize
Downloadimage/jpeg utilpipelinecrash.jpg520.91 KB

I have filed this bug for you.

Quote:

David Lu (Intel) wrote:

I have filed this bug for you.

Thanks a lot ;-)

cheers
SMing 

SMing,
Is issue still reproducible on Gold release available on http://intel.com/software/perceptual?
If yes, can you provide more instructions how to reproduce (which sample app, or source code of reproducer)?

Quote:

Mikhail Nikolsky (Intel) wrote:

SMing,
Is issue still reproducible on Gold release available on http://intel.com/software/perceptual?
If yes, can you provide more instructions how to reproduce (which sample app, or source code of reproducer)?

Hi Mikhail,

Thanks for the pointer to the gold release, I didn't know about the release until you mentioned this.
I will update my sdk and check it again. So, will get back to you, thanks!

cheers
SMing 

 

Hi Mikhail,

Just updated to the latest gold release and yes, the crash is unfortunately still there  :-(
Note that such crash would only happen when the application is started during the absence of the cam. Otherwise, things are fine. 

Anyway, this is the pseudo-code and the corresponding steps for the repro: 

1: Make sure the creative cam is not connected to the system
2. Start your app...  Internal: create a session with PXCSession_Create
3. Instantiate a derived UtilPipeline instance with the newly created Session.
4. Inside the constructor of UtilPipeline derived class, make the following common setups:
- EnableGesture ();
- EnableVoiceRecognition ();
- SetVoiceCommands (voiceCommands);
5. Start the processing loop by invoking UtilPipeline::LoopFrames or UtilPipeline::Init method for manual loop.
6. Either way, the fatal error occurs 100% deep down in the UtilPipeline::Init call somewhere around the _invoke_watson call (as seen from the debug call stack)

ps: please refer to the attached PNG for more details on the callstack at the crash spot.

Setup:
Windows 8 Pro 64-bit
PC SDK Gold Release
Library variant: v100 platform Toolset (32-bit)
VS 2010 - Debug build (32-bit)
Dependency: libpxcutils_d.lib (32-bit)

cheers
SMing

Attachments: 

AttachmentSize
Downloadimage/png utilpipeline.png156.24 KB

Please download our latest SDK release and see if you still have this issue. Thanks.

Quote:

SMing wrote:

Just updated to the latest gold release and yes, the crash is unfortunately still there  :-(

Hi David,

i think SMing already reproduced it on Gold version

The issue reproduced and root caused to utility library.

To fix it, please modify 'vidx' to 'aidx' in file sample\common\src\util_pipeline_voice.cpp line 101 and recompile libpxcutils project:

        else ainputs[vidx]=&m_vrec_pinfo.inputs;
should be
        else ainputs[aidx]=&m_vrec_pinfo.inputs;

 

Hi Mikhail,

Many thanks for solving this! Yes, the correction fixed the crash right away after recompiled with the corrected util library.
It's great to know that the library source codes are open to external developers too! I wasn't aware of this until you pointed out the fix  ;-p

By the way, am wondering if there's a plan to improve the Util library in Intel such that the UtilPipeline::IsDisconnected can also be used to check the camera status before the Init call? This allows the application to alert the users about the situation before starting the processing loop, etc. Frankly, I am thinking of expanding this method locally here under the motivation that one should hide/encapsulate such complexity within the utility library itself. Thanks.

cheers
SMing

Leave a Comment

Please sign in to add a comment. Not a member? Join today