You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have some stability issues with an application that is using the Doosan API. We narrowed it down to calling the set_tool function. For some reason, a heap corruption occurs after a while. I already tried to increase the sleep time in between
Example code:
We assume a connection is already made, the API has control and the robot is in manual mode.
while (true)
{
Sleep(500);
if (!Drfl.set_tool("tool"))
{
std::cout << "Set tool failed";
}
Sleep(500);
if (!Drfl.set_tool("tool2"))
{
std::cout << "Set tool2 failed";
}
i++;
if (i % 10 == 0)
{
std::cout << "Iteration: " << i << "\n";
}
}
Critical error detected c0000374
A breakpoint instruction (__debugbreak() statement or a similar call) was executed in DoosanAPICPP.exe.
Exception thrown at 0x00007FFA6A73BE19 (ntdll.dll) in DoosanAPICPP.exe: 0xC0000374: Er is een heap beschadigd (parameters: 0x00007FFA6A7B1860).
After not that many runs (30-500) the application crashes with a heap corruption.
Versions
DRFL: GL010118
ROBOT: GF02100101
The text was updated successfully, but these errors were encountered:
Some additional feedback. It seems to depend on the length of the tool name. I tried to rerun the example above in the simulator and didn't get the issue. Then tried back on a live robot and it happened again. The only difference were the tool names. It appears the toolname length should be long enough (in my test 18 characters did the trick). This might have something to do with short string being kept on the stack and long strings being transferred to the heap (short string optimization)
We have some stability issues with an application that is using the Doosan API. We narrowed it down to calling the set_tool function. For some reason, a heap corruption occurs after a while. I already tried to increase the sleep time in between
Example code:
We assume a connection is already made, the API has control and the robot is in manual mode.
After not that many runs (30-500) the application crashes with a heap corruption.
Versions
DRFL: GL010118
ROBOT: GF02100101
The text was updated successfully, but these errors were encountered: