Debugging ROS2 in Visual Studio

1,590 views
Skip to first unread message

Brad Baillio

unread,
Apr 27, 2016, 2:04:08 PM4/27/16
to ROS SIG NG ROS
Has anyone tried this? Has anyone had success?
I've been tinkering with it, and I can get my app to run, but it quickly crashes when creating the node object. It's always crashing on a bad memory allocation.

Unhandled exception at 0x00007FFB9B811F28 in talker.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x000000D8FE3BCEE0.

This is where it breaks to on the crash:


Morgan Quigley

unread,
Apr 27, 2016, 2:11:00 PM4/27/16
to ros-sig...@googlegroups.com
Hi Brad,

The Windows binaries are built and run on the CI farm using the Visual Studio command-line tools, so I would expect that things would work. Can you describe the problem in a bit more detail (e.g., Windows and Visual Studio version, which RMW implementation you're using, and which executable(s) are running at the time of the crash, if you built them yourself or are using the pre-built versions, etc.) so that we can reproduce it?

Best regards,
Morgan

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Brad Baillio

unread,
Apr 27, 2016, 2:20:01 PM4/27/16
to ROS SIG NG ROS
I'm running Windows 10, with the VS 2015 community edition.
I, too, can compile and run everything just fine in the command-line tools.

I would like to open the VS solution, and debug things inside VS. That would be epic.

So, I've compiled the alpha5 release of ROS2 and the community OpenSplice.
  1. I do an ament build on my custom app, which builds successfully.
  2. I open the VS solution found in the build directory
  3. I add to the project properties->Debugging->Environment: PATH=%PATH%;C:\path\to\ROS2\dlls;C:\path\to\OpenSplice\dlls;
  4. I start the debug of my custom app
This is when it crashes as indicated above.

Brad Baillio

unread,
Apr 27, 2016, 2:22:15 PM4/27/16
to ROS SIG NG ROS
The custom app is a simple talker/lisener.
I tried debugging each one, and neither gets past the node creation successfully.

Jackie Kay

unread,
Apr 27, 2016, 2:22:54 PM4/27/16
to ros-sig...@googlegroups.com
I use VS2015 mostly when there's a memory problem or race condition specific to Windows and I need to use the Visual Studios debugger.

Personally I'm a bit allergic to GUIs, so I try to avoid Visual Studios when I can--since we do most of our development on Unix first, the Windows dev environment is rough around the edges. But we want the ROS 2 Visual Studios experience to be functional, especially because that would mean bringing in more Windows people to test and develop ROS 2. So we want to hear your feedback about how we can make this better.

this is my general workflow:

- ament build my workspace in command prompt A
- in command prompt B, cd to the top level of your ament workspace and "call install\setup.bat". make sure this command prompt is a "VS2015 x86 Native Tools Command Prompt"! command prompt A probably has to be a Native Tools command prompt, too.
- in command prompt B, use "devenv" to open Visual Studios
- In VS, open the .sln file for the package which contains your executable, e.g. ros2_ws\build\rclcpp_examples\rclcpp_examples.sln
- sometimes I need a magical unknown step where I have to "Rebuild this project" for things to work. If it asks me about rebuilding out of date projects, I usually ignore it because I've already used ament to build the dependencies...
- then, I usually right click on the executable name in "Solution Explorer" (e.g. "talker"), select "Debug" and "Start New Instance" if I want to use the debugger. This seems to work most reliably IF you've built the entire workspace with --cmake-args -DCMAKE_BUILD_TYPE=Debug --.
  - alternatively I choose "Debug" in the top bar and "Start Without Debugging"



On Wed, Apr 27, 2016 at 11:04 AM, Brad Baillio <brad.b...@gmail.com> wrote:

William Woodall

unread,
Apr 27, 2016, 2:26:09 PM4/27/16
to ROS SIG NG ROS
Jackie's outline is what I do as well. Using VS works for me every time I've used it. The error you're talking about might just be an error, brought about by how you're using our API, but I'm not sure.
--
William Woodall
ROS Development Team

Brad Baillio

unread,
Apr 27, 2016, 2:47:34 PM4/27/16
to ROS SIG NG ROS
OK. I tried following Jackies instructions for rclcpp_examples.sln. I still am having issues, but I'm going to do a clean build of alpha5 and try again.
Invoking the setup.bat and then opening VS from the command-line seems a better way of getting the environment setup properly.

I'll see if I can make it work. It's good to hear that you are all successful. At least I know it's possible.

Brad Baillio

unread,
Apr 27, 2016, 4:44:24 PM4/27/16
to ROS SIG NG ROS


On Wednesday, April 27, 2016 at 12:22:54 PM UTC-6, Jackie Kay wrote:
I use VS2015 mostly when there's a memory problem or race condition specific to Windows and I need to use the Visual Studios debugger.

Personally I'm a bit allergic to GUIs, so I try to avoid Visual Studios when I can--since we do most of our development on Unix first, the Windows dev environment is rough around the edges. But we want the ROS 2 Visual Studios experience to be functional, especially because that would mean bringing in more Windows people to test and develop ROS 2. So we want to hear your feedback about how we can make this better.

this is my general workflow:

- ament build my workspace in command prompt A
- in command prompt B, cd to the top level of your ament workspace and "call install\setup.bat". make sure this command prompt is a "VS2015 x86 Native Tools Command Prompt"! command prompt A probably has to be a Native Tools command prompt, too.

So far I've only been using the "VS2015 x64 Native Tools Command Prompt". Are you really using the x86 version for this to work?
 
- in command prompt B, use "devenv" to open Visual Studios
- In VS, open the .sln file for the package which contains your executable, e.g. ros2_ws\build\rclcpp_examples\rclcpp_examples.sln
- sometimes I need a magical unknown step where I have to "Rebuild this project" for things to work. If it asks me about rebuilding out of date projects, I usually ignore it because I've already used ament to build the dependencies...
- then, I usually right click on the executable name in "Solution Explorer" (e.g. "talker"), select "Debug" and "Start New Instance" if I want to use the debugger. This seems to work most reliably IF you've built the entire workspace with --cmake-args -DCMAKE_BUILD_TYPE=Debug --.

When I try to do this, it doesn't compile because it's looking for python debug library. Are you guys compiling this manually on windows for this to work?

William Woodall

unread,
Apr 27, 2016, 4:46:56 PM4/27/16
to ROS SIG NG ROS
On Wed, Apr 27, 2016 at 1:44 PM, Brad Baillio <brad.b...@gmail.com> wrote:


On Wednesday, April 27, 2016 at 12:22:54 PM UTC-6, Jackie Kay wrote:
I use VS2015 mostly when there's a memory problem or race condition specific to Windows and I need to use the Visual Studios debugger.

Personally I'm a bit allergic to GUIs, so I try to avoid Visual Studios when I can--since we do most of our development on Unix first, the Windows dev environment is rough around the edges. But we want the ROS 2 Visual Studios experience to be functional, especially because that would mean bringing in more Windows people to test and develop ROS 2. So we want to hear your feedback about how we can make this better.

this is my general workflow:

- ament build my workspace in command prompt A
- in command prompt B, cd to the top level of your ament workspace and "call install\setup.bat". make sure this command prompt is a "VS2015 x86 Native Tools Command Prompt"! command prompt A probably has to be a Native Tools command prompt, too.

So far I've only been using the "VS2015 x64 Native Tools Command Prompt". Are you really using the x86 version for this to work?

I think her VM might be 32-bit, I use 64-bit and the x64 command prompt too.
 
 
- in command prompt B, use "devenv" to open Visual Studios
- In VS, open the .sln file for the package which contains your executable, e.g. ros2_ws\build\rclcpp_examples\rclcpp_examples.sln
- sometimes I need a magical unknown step where I have to "Rebuild this project" for things to work. If it asks me about rebuilding out of date projects, I usually ignore it because I've already used ament to build the dependencies...
- then, I usually right click on the executable name in "Solution Explorer" (e.g. "talker"), select "Debug" and "Start New Instance" if I want to use the debugger. This seems to work most reliably IF you've built the entire workspace with --cmake-args -DCMAKE_BUILD_TYPE=Debug --.

When I try to do this, it doesn't compile because it's looking for python debug library. Are you guys compiling this manually on windows for this to work?

There's some extra work you need to do if you want to build in Debug on Windows: https://github.com/ros2/ros2/wiki/Windows-Development-Setup#extra-stuff-for-debug-mode
 

 
  - alternatively I choose "Debug" in the top bar and "Start Without Debugging"



On Wed, Apr 27, 2016 at 11:04 AM, Brad Baillio <brad.b...@gmail.com> wrote:
Has anyone tried this? Has anyone had success?
I've been tinkering with it, and I can get my app to run, but it quickly crashes when creating the node object. It's always crashing on a bad memory allocation.

Unhandled exception at 0x00007FFB9B811F28 in talker.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x000000D8FE3BCEE0.

This is where it breaks to on the crash:


--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Morgan Quigley

unread,
Apr 27, 2016, 4:48:08 PM4/27/16
to ros-sig...@googlegroups.com
Yes, we're compiling Python in debug mode. At the bottom of this page:

https://github.com/ros2/ros2/wiki/Windows-Development-Setup

There is a walkthrough for how to do that.

On Wed, Apr 27, 2016 at 1:44 PM, Brad Baillio <brad.b...@gmail.com> wrote:

Brad Baillio

unread,
Apr 27, 2016, 4:48:47 PM4/27/16
to ROS SIG NG ROS
And compiling everything as Debug is the best (only?) way for this to work?

William Woodall

unread,
Apr 27, 2016, 4:55:00 PM4/27/16
to ROS SIG NG ROS
Mixing debug and release dll's on Windows is considered bad practice and may cause you other problems which distract you from the issue you're debugging:


So on Windows I think you should either do all debug or all release. You can try mixing them, but unlike Unix platforms where it typically "just works" (still not guaranteed) on Windows you're very likely to cause new problems.

Brad Baillio

unread,
Apr 27, 2016, 5:08:46 PM4/27/16
to ROS SIG NG ROS
So a follow-up question, then, is if there will ever be ROS2 debug binariy artifacts to grab from GitHub?

If not, that's fine. We can always make our own for local distribution.

Thanks for the help everyone!

Brad Baillio

unread,
Apr 27, 2016, 5:24:42 PM4/27/16
to ROS SIG NG ROS
So, are you guys also compiling OpenSplice in debug mode? And linking that into the ROS2 debug build?
By this logic, you would have to...right?

Brad Baillio

unread,
Apr 27, 2016, 5:28:02 PM4/27/16
to ROS SIG NG ROS
Another really great workflow for people like me, who only wants to build on top of ROS2, is the RelWithDebInfo mode in Visual Studio. That works just fine using the ROS2 Release version. :-)

William Woodall

unread,
Apr 27, 2016, 8:54:11 PM4/27/16
to ROS SIG NG ROS
I've had to debug with opensplice on Windows only once I think, and I believe I built opensplice from source as debug in order to do so. I'm not sure our CMake infrastructure can handle release and debug versions of opensplice side by side. It can do this for Connext though (mostly because connext distributes their release and debug libraries with different names and we had to support that one time in order to debug into their libraries).
Reply all
Reply to author
Forward
0 new messages