Welcome to the "debugging" knowledge base article of Vision Point API. Please refer to this content list:

• • Linux blocking calls and signals in the streaming thread
  • Prevent gdb interruption on SIG44 during debug in Linux
  • How to handle first-chance exceptions
  • Included debug tools
    • Vision Point I

Linux blocking calls and signals in the streaming thread

In Linux, user should not use blocking calls and blocking operations (such as reading std::cin) in the same thread, which is subscribed to signals, i.e. in the thread where 'KYFG_Open()' function was called.

There are two possible solutions to overcome this:

• Use different threads for KYFG_Open() and std::in, as well as for any other blocking operations such as reading/writing files, etc.
• Use 'KYFGLib_Initialize()' function, described in "Vision Point API Data Book" document, before opening any Frame Grabber, cameras and starting streams, and add 'KYFGLIB_CONCURRENCY_SA_RESTART' to the "concurrency_mode" field of the passed 'KYFGLib_InitParameters' instance.

The 1st approach is preferred over the 2nd one because using. 'KYFGLIB_CONCURRENCY_SA_RESTART' may impact stream performance in certain circumstances. This is because what this flag usually means is that your blocking thread will still be interrupted by a signal, but the operating system will just save that thread state, switch context to signal handling procedure and then restore the context to proceed with the blocking call.

Prevent gdb interruption on SIG44 during debug in Linux

When running KAYA's KYFGLib library under a debugging tool, the signal (SIG44), sent from kernel to the user space stops the application.

In order to prevent the debugger from stopping the application when signals are sent, it is advised to setup gdb to ignore them during debugging.

For example:

1. Create the "~/.gdbinit" file
2. Add the "handle SIG44 nostop noprint pass" string to this file
3. Restart the environment

How to handle first-chance exceptions?

When an exception is first thrown, whether from the application itself or dependent or platform code, it is known as a "first-chance" exception. It is not an actual exception that indicates a real problem, but a debugging instrument for C++ code that uses exceptions in normal flow.

The user can edit the debugger settings to disable those "implicit breakpoints" caused by first chance exceptions. An example of this type of exception is shown in the image below:

How to manage "first-chance" exceptions in this Microsoft article: Manage exceptions with the debugger (make sure to expand the "C++ Exceptions" group of "Exception Settings")

The "first-chance" exceptions can be managed by either disabling all C++ exceptions except those explicitly enabled:	Or by enabling all exceptions except those explicitly disabled can be as seen in the image below:

Note: You can prevent the first chance warning from appearing in the output window of Visual Studio using its context menu (right-click) when it is showing output from "Debug." 

Included debug tools

Vision Point installation comes with a bunch of debug tools. This tools is useable mostly for internal debugging process, but you can use it in some cases if you know what you doing.

The hierarchy and a brief description:

Vision Point I