When type: string is specified in a struct field in IDL, the generated type is StringData. StringData does not own the data it points to, and as a result the data it points to may outlive the StringData object itself. This can be problematic if the data is freed, which would cause the StringData object to point to garbage memory and may lead to a segfault.

This particularly happens when an IDL struct is used for a command's parameters. When the command returns, the parameters are destructed causing the StringData object to point to garbage. Here's an example of this happening. In this case, a workaround was made by creating an object that holds a std::string in IDL. However, a more direct fix could be achieved if the type of a struct field in IDL could be a std::string rather than StringData.