-
-
Notifications
You must be signed in to change notification settings - Fork 537
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
Compiles with sol 3.3.0 working only in debug mode while release builds break. #1459
Comments
I isolated the error in my vcode (used to work flawlessly in the past):
|
It seems my build works again in release mode with |
Some of them are definitely introducing runtime overhead. For |
Since I'm writing a gameserver, for us performance is critical. |
So - the error lies here: sol2/include/sol/usertype_container.hpp Lines 527 to 543 in eba8662
The upper code branch compiles on debug and on release, while the lower branch for my code leads to an error in release mode. I have no idea why, or what to do to fix it.
The error:
For some reason it has an issue with "arg" in release mode if no safeties are enabled. |
Just for completeness - wondering if it is the member I am trying provide as "arg":
and
I just realized that removing the shared_ptr made that code compile and the same problem coming up at another location where I tried to expose some std::shared_ptr. This attempt also failed:
So - could I expose shared_ptr or is there an issue? |
So after removing the shared_ptr from the variant and removing the shared_string_table, now the compiles work without safeties again. |
I tried something more intuitively than knowing what I was doing. sol2/include/sol/usertype_container.hpp Line 541 in eba8662
into this:
And my sorrows went away. Please someone explain if this is OK and could be used as a fix or is just utter hack and will make things explode in the near future. |
I resorted to asking ChatGPT and that's the answer I got. ChatGPT answer: I see what you did there! By changing the return statement to return stack::unqualified_get<T>(L_, 1);, you're dereferencing the pointer returned by stack::unqualified_get<T*>(L_, 1) and returning a reference to the object pointed to by the pointer. Here's why this works: When you pass a usertype to a Lua function using Sol2, Sol2 stores a pointer to the object in the Lua registry. When the Lua function is called, Sol2 retrieves this pointer and passes it to the C++ function. By default, Sol2 uses stack::unqualified_get to retrieve the pointer from the Lua stack. However, when Sol2 safeties are turned off, stack::unqualified_get returns a raw pointer to the object in the Lua registry. This means that if you have a usertype that uses a smart pointer to manage its lifetime, Sol2 won't be able to tell when the object has been deleted. By changing the return statement to return stack::unqualified_get<T>(L_, 1);, you're dereferencing the raw pointer returned by stack::unqualified_get<T*>(L_, 1) and returning a reference to the object pointed to by the pointer. This means that Sol2 can properly manage the lifetime of the object using the smart pointer. Note that this approach only works if your usertype is designed to work with raw pointers. If your usertype is designed to work with smart pointers, you should consider using std::shared_ptr or std::unique_ptr to manage the lifetime of your objects. I hope this helps! Let me know if you have any more questions. |
I finally worked around the issue by replacing the variant type stored in a vector with a variant wrapper with dedicated getters and constructors so Lua can understand it. |
I had a project resting for a while and am picking it up again and I now have broken builds in release mode while debug builds still work.
I tried using older versions of sol but it didn't change.
Ofc there were some changes in the codebase - e.g. using C++20 now.
I am not sure I'm able to produce a minimal example shortly, so I'm just providing the error message here,
maybe it's sufficient for people in the know of the sol2 intestines .
Error message:
The text was updated successfully, but these errors were encountered: