while debugging our application we often have the problem that a breakpoint is triggered in another thread (mostly in std::string ctor) when we want to step into a function call.
This is making debugging harder and annoying. Did someone else also encounter this problem?
Here is the test application to reproduce the problem, just create a new console application and use the code below. Set a breakpoint on the function call and press F11 to step into the function when the breakpoint is reached.
static DWORD WINAPI ThreadProc(LPVOID pvarg)
void TestFunction(const std::string& s)
int wmain(int argc, wchar_t *argv)
CreateThread(0, 0, ThreadProc, 0, 0, 0);
// set a breakpoint on the function call below
// press F11 to step into the function when the breakpoint is reached
TestFunction doesn’t have any code. that might trigger next statement execution will be in a thread. Please write some statement on the TestFunction and see the behavior.
Right click on the breakpoint statement and “Go to Disassmbly” and see the assembly instructions what compiler is generated.
i have added a NkDbgPrintfW-statement in TestFunction, but this doesn’t make a difference.
I could reduce the problem even more, just creating an instance of std::string in the main thread triggers a breakpoint if i try to step into the constructor of std::string.
It seems like this could be a problem when 2 different threads are calling the constructor of std::string at the same time???
I have attached 2 screenshots, the first is when the breakpoint is reached, the seconds is after pressing F11 to step into the constructor of std::string.
It is not a problem of the constructor of std::string, trying to step into “Sleep” with F11 in the main thread triggers the breakpoint if another thread is already in the “Sleep” function.
We are tested Apalis IMX6 1.3 b2 image, could not able to reproduce the issue. Moreover, this problem would be in Visual Studio 2015 and application builder for Windows Embedded Compact 2013.
we’re seeing this problem on 3 different developer machines.
We’re using VS2013 Update 5 for development. I updated to the latest version of application builder (12.0.60801), but the problem is still there.
We’re still on 1.2b6, but we already had this problem on all previous BSP versions, so i don’t think it will be fixed when we update to 1.3b2.
One of our colleagues also faced a similar issue with Update 5. So, Could you try Visual studio 2013 updates or Visual Studio 2015?
There are no updates for VS2013 available, we’re already on the latest version.
I’ll try it with VS2015 in a virtual machine, but i’m busy at the moment so this could take a while.
The problem happens with VS2015 too
I have set up a brand new virtual machine with VS2015 14.0.25431.01 Update 3, application builder 14.0.25520 and Toradex SDK 2.2.
We’re running a custom OS (BSP 1.2b6) on a custom carrier board.
I don’t have a toradex carrier board available, so I can’t test it with a standard toradex OS.
We are able to reproduce the problem. Could you please wait for few days, we will get back soon with details.
Do you have any news on the issue?
We did some further investigations on different platforms. Seems to be an issue for all of them. This more kind of a inconvenience of the ARM debugger. Let me explain:
If you press F11 on the Sleep() function the debugger sets a break point in the first instruction of the sleep function in the background. If the same function is also called the same time from an other thread it will also break because the Sleep function is a global function.
The same also happens if you press F11 on TestFunction in your original code (TestFunction("???");). If you press F11 here, the break point will be set in the string constructor. So if your other thread also calls the the string constructor with the line std::string s("???"); you will also end up with a break point there.
I also would say this is an inconvenience of the ARM debugger. I checked with the X86 debugger and this does not happen there.
Thanks for your investigations, seems like we have to live with that.
It doesn’t happen too often, but it is really annoying when it happens.