Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Library crashing when using set_tool too many times #28

Open
pconfig opened this issue Jun 23, 2023 · 1 comment
Open

Library crashing when using set_tool too many times #28

pconfig opened this issue Jun 23, 2023 · 1 comment

Comments

@pconfig
Copy link

pconfig commented Jun 23, 2023

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

@pconfig
Copy link
Author

pconfig commented Jun 24, 2023

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant