-
Notifications
You must be signed in to change notification settings - Fork 100
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
Better error when compiled artifacts are in use #257
Comments
I think on Unix, you will get
Though this is not completely reliable and might be removed in the future, c.f. https://lwn.net/Articles/866493/ Depending on how copying files is actually done, this might also not be a problem at all, i.e. if the new file is moved to replace the old one, then there is no issue as the old file sticks around until no more process has it opened. |
Oh, good to know. I think when I've seen segfaults before it was for libraries rather than executables. Might behave differently? This is just a "nice to have" thing for development so I probably won't try to implement this any time soon. Just a passing thought. |
I think this mostly happens because updates are not transactional, e.g. an older executable will after having been started dynamically load a newer library that has an different ABI the older version of the library. But as written above, |
From the article you linked above:
It really does sound to me like shared libraries don't get |
Indeed, the removal seems to be further along than I remembered from reading the article. Appears like I did not read it very thoroughly. 😊 |
So for extensions modules which are shared libraries |
Not at all! Always worth sharing information and debating my spurious claims of segfaults 😂 |
When the built shared library is copied to the correct location, it actually *modifies* any existing shared library, which causes any running process using it to segfault. To fix this, we first delete any existing shared library (which is safe to do) and then copy the newly built shared library to the correct location as a new file. Related to PyO3#257
* Fix segfaults caused by modifying existing shared library When the built shared library is copied to the correct location, it actually *modifies* any existing shared library, which causes any running process using it to segfault. To fix this, we first delete any existing shared library (which is safe to do) and then copy the newly built shared library to the correct location as a new file. Related to #257 * Use os.rename * Use os.replace * Update setuptools_rust/build.py Co-authored-by: Adam Reichold <adamreichold@users.noreply.github.com> * Update changelog Co-authored-by: Adam Reichold <adamreichold@users.noreply.github.com>
I was thinking the other day it might be nice to check if any processes are using the installed extension before attempting to copy across.
I think on Windows we'll get an
OsError
raised during copy, and on Unix any running processes are just likely to crash when they next need to load a segment of the native code.Doing a check and raising our own friendly error might be nicer UX.
The text was updated successfully, but these errors were encountered: