REDHAWK component debugging

2019-09-14 17:43发布

问题:

I can't get debugging to work.

I'm using the 2.1.0 version of REDHAWK and I'm trying to create custom components.

I can get release version to run and to work.

Here's what I do, I have created a very basic custom component that takes input, multiplies it by two and pushes it to the output stream, super simple. Now I try to run this component in debug mode in sandbox, instant crash. The only this I can see is the last entry of the callstack, which is

boost::shared_ptr<rh_logger::Logger>::operator->() at shared_ptr.hpp:653

If I choose to run my component without debugging, everything works. It even does the multiplication.

I have no idea what goes on, apparently this smart pointer class does a assert check to validate the pointer that it returns and ends up crashing because it's zero. Being the -> operator, this seems quite dangerous. SIGSEGV is the error being throw, I wonder if BOOST_ASSERT causes that on failure?


Operating system is CentOS 7 64 bit and it's running on regular desktop intel processor, can't remember which.

I installed REDHAWK by downloading the repository as instructed in 2.2 part of the REDHAWK manual.

The new component was created with the REDHAWK IDE (eclipse based), I selected C++ as the Program language. It seems to be a shared library and when I run it, a process called ComponentHost is started.

I'm trying to start the component in the sandbox via right-clicking the component in the Project menu and selecting Debug as - Component in the Sandbox. Running the component in the Release mode this way works.

回答1:

I'm able to debug a component via the Python sandbox, so just a couple of variables to help narrow it down, with my test system in []:

  1. Which operating system? [CentOS 7]
  2. REDHAWK installed from source or RPM? [RPM]
  3. Is this a new C++ shared library-based component (entry point type is "SharedLibrary") or executable ("Executable")? [both]
  4. How are you launching the component? Via the Python sandbox, with with "debugger='gdb'" as an argument to launch? Any other launch arguments?

Another possible debugging approach is to launch the component normally, then attach GDB from another terminal window.

First, find the component process:

  • If it's a shared library:

    ps -o pid,comm -C ComponentHost

  • If it's an executable (where "" is the component executable's name):

    ps -o pid,cmd -C <name>

Hopefully, it's clear which process is your target component. If you're running multiple shared library components from the same sandbox, they will all be part of the same ComponentHost instance.

Then, attach to the process with GDB:

gdb -p <pid>

This is essentially how the sandbox attaches GDB; however, running it independently allows you to set the flow up to your liking first before attaching the debugger.



标签: redhawksdr