Patches sometimes do not apply #235
Assignees
Comments
|
An initial hypothesis was that it was related to minSdkVersion, but I believe @felangel tried and decided it repro'd with the default v16 from Flutter too? |
|
Notes:
Logs |
|
Log from my run just now: |
|
I'm. not sure which version of the updater library the current Time Shift is using, but if it's current to head, then the fact that we don't see a message from "get_base_path" "File does not exist" would suggest the file does exist? Although I would expect to see a "file does not exist" from the first entry "libapp.so", suggesting this may not be fully up to date. |
|
Felix and I discussed and decided we need to get this current release out (with all the updates to the updater logging) before we can debug this. So this will have to be punted to early next week for fixing. :( |
|
We have a theory! We think this is just a string handling bug from C++. the .sor.so is likely that it's re-using the same buffer as was used for libflutter.so with libapp.so but libapp.so is a shorter string and when overlayed is libapp.sor.so We'll check our C++ string handling tomorrow, but I think we'll find the bug there. |
eseidel
added a commit
to shorebirdtech/engine
that referenced
this issue
Apr 7, 2023
Fixes shorebirdtech/shorebird#235 The root cause was we were not terminating the strings passed for original_libapp_paths. We used a Vector<char> but didn't append a '\0' to the end before calling data(), so when the c/rust side walked to find the end of the char* it sometimes found extra characters at the end of the string unexpectedly. This fixes to use a shorter (but probably equally dangerous?) method of using c_str() which we had tried before but previously had used c_str() on a temporary. This attempt carefully uses a reference to the string so the c_str()'s lifetime is tied to the string in application_library_paths rather than a temporary copy. This is still slightly dangerous in that c_str() lives as long as a std::string does, so long as it's not modified.
eseidel
added a commit
to shorebirdtech/engine
that referenced
this issue
Apr 7, 2023
* Fix unterminated string causing flaky behavior. Fixes shorebirdtech/shorebird#235 The root cause was we were not terminating the strings passed for original_libapp_paths. We used a Vector<char> but didn't append a '\0' to the end before calling data(), so when the c/rust side walked to find the end of the char* it sometimes found extra characters at the end of the string unexpectedly. This fixes to use a shorter (but probably equally dangerous?) method of using c_str() which we had tried before but previously had used c_str() on a temporary. This attempt carefully uses a reference to the string so the c_str()'s lifetime is tied to the string in application_library_paths rather than a temporary copy. This is still slightly dangerous in that c_str() lives as long as a std::string does, so long as it's not modified. * Fix comments
|
I believe this is fixed. |
|
Reopening this since it appears we only addressed part of the issue. There still remains a scenario in which the libapp.so is not found. I'm investigating further now and will report back with more notes/observations. Notes
NativeLibrary::NativeLibrary(const char* path) {
::dlerror();
handle_ = ::dlopen(path, RTLD_NOW);
if (handle_ == nullptr) {
FML_DLOG(ERROR) << "Could not open library '" << path << "' due to error '"
<< ::dlerror() << "'.";
}
} |
|
I have a fix written: shorebirdtech/updater#5 I will figure out a workaround so I can test it. |
eseidel
added a commit
to shorebirdtech/updater
that referenced
this issue
Apr 12, 2023
… it on disk (#5) Fixes shorebirdtech/shorebird#235 🤞 This moves us away from depending on libapp.so having been extracted from the APK and instead we always extract it ourselves.
github-project-automation
bot
moved this from In Progress
to Done
in 0.0.8: adding more TTs
eseidel
added a commit
to shorebirdtech/engine
that referenced
this issue
Apr 12, 2023
felangel
pushed a commit
to shorebirdtech/engine
that referenced
this issue
Jun 6, 2023
* Fix unterminated string causing flaky behavior. Fixes shorebirdtech/shorebird#235 The root cause was we were not terminating the strings passed for original_libapp_paths. We used a Vector<char> but didn't append a '\0' to the end before calling data(), so when the c/rust side walked to find the end of the char* it sometimes found extra characters at the end of the string unexpectedly. This fixes to use a shorter (but probably equally dangerous?) method of using c_str() which we had tried before but previously had used c_str() on a temporary. This attempt carefully uses a reference to the string so the c_str()'s lifetime is tied to the string in application_library_paths rather than a temporary copy. This is still slightly dangerous in that c_str() lives as long as a std::string does, so long as it's not modified. * Fix comments
felangel
pushed a commit
to shorebirdtech/engine
that referenced
this issue
Jun 6, 2023
#8) * Bump updater dependency to include fix for shorebirdtech/shorebird#235
felangel
pushed a commit
to shorebirdtech/engine
that referenced
this issue
Jun 6, 2023
* Fix unterminated string causing flaky behavior. Fixes shorebirdtech/shorebird#235 The root cause was we were not terminating the strings passed for original_libapp_paths. We used a Vector<char> but didn't append a '\0' to the end before calling data(), so when the c/rust side walked to find the end of the char* it sometimes found extra characters at the end of the string unexpectedly. This fixes to use a shorter (but probably equally dangerous?) method of using c_str() which we had tried before but previously had used c_str() on a temporary. This attempt carefully uses a reference to the string so the c_str()'s lifetime is tied to the string in application_library_paths rather than a temporary copy. This is still slightly dangerous in that c_str() lives as long as a std::string does, so long as it's not modified. * Fix comments
felangel
pushed a commit
to shorebirdtech/engine
that referenced
this issue
Jun 6, 2023
#8) * Bump updater dependency to include fix for shorebirdtech/shorebird#235
eseidel
added a commit
to shorebirdtech/engine
that referenced
this issue
Jun 8, 2023
* Fix unterminated string causing flaky behavior. Fixes shorebirdtech/shorebird#235 The root cause was we were not terminating the strings passed for original_libapp_paths. We used a Vector<char> but didn't append a '\0' to the end before calling data(), so when the c/rust side walked to find the end of the char* it sometimes found extra characters at the end of the string unexpectedly. This fixes to use a shorter (but probably equally dangerous?) method of using c_str() which we had tried before but previously had used c_str() on a temporary. This attempt carefully uses a reference to the string so the c_str()'s lifetime is tied to the string in application_library_paths rather than a temporary copy. This is still slightly dangerous in that c_str() lives as long as a std::string does, so long as it's not modified. * Fix comments
eseidel
added a commit
to shorebirdtech/engine
that referenced
this issue
Jun 8, 2023
#8) * Bump updater dependency to include fix for shorebirdtech/shorebird#235
felangel
pushed a commit
to shorebirdtech/engine
that referenced
this issue
Jun 8, 2023
* Fix unterminated string causing flaky behavior. Fixes shorebirdtech/shorebird#235 The root cause was we were not terminating the strings passed for original_libapp_paths. We used a Vector<char> but didn't append a '\0' to the end before calling data(), so when the c/rust side walked to find the end of the char* it sometimes found extra characters at the end of the string unexpectedly. This fixes to use a shorter (but probably equally dangerous?) method of using c_str() which we had tried before but previously had used c_str() on a temporary. This attempt carefully uses a reference to the string so the c_str()'s lifetime is tied to the string in application_library_paths rather than a temporary copy. This is still slightly dangerous in that c_str() lives as long as a std::string does, so long as it's not modified. * Fix comments
felangel
pushed a commit
to shorebirdtech/engine
that referenced
this issue
Jun 8, 2023
#8) * Bump updater dependency to include fix for shorebirdtech/shorebird#235
felangel
pushed a commit
to shorebirdtech/engine
that referenced
this issue
Jun 16, 2023
* Fix unterminated string causing flaky behavior. Fixes shorebirdtech/shorebird#235 The root cause was we were not terminating the strings passed for original_libapp_paths. We used a Vector<char> but didn't append a '\0' to the end before calling data(), so when the c/rust side walked to find the end of the char* it sometimes found extra characters at the end of the string unexpectedly. This fixes to use a shorter (but probably equally dangerous?) method of using c_str() which we had tried before but previously had used c_str() on a temporary. This attempt carefully uses a reference to the string so the c_str()'s lifetime is tied to the string in application_library_paths rather than a temporary copy. This is still slightly dangerous in that c_str() lives as long as a std::string does, so long as it's not modified. * Fix comments
felangel
pushed a commit
to shorebirdtech/engine
that referenced
this issue
Jun 16, 2023
#8) * Bump updater dependency to include fix for shorebirdtech/shorebird#235
eseidel
added a commit
to shorebirdtech/engine
that referenced
this issue
Jun 22, 2023
* Fix unterminated string causing flaky behavior. Fixes shorebirdtech/shorebird#235 The root cause was we were not terminating the strings passed for original_libapp_paths. We used a Vector<char> but didn't append a '\0' to the end before calling data(), so when the c/rust side walked to find the end of the char* it sometimes found extra characters at the end of the string unexpectedly. This fixes to use a shorter (but probably equally dangerous?) method of using c_str() which we had tried before but previously had used c_str() on a temporary. This attempt carefully uses a reference to the string so the c_str()'s lifetime is tied to the string in application_library_paths rather than a temporary copy. This is still slightly dangerous in that c_str() lives as long as a std::string does, so long as it's not modified. * Fix comments
eseidel
added a commit
to shorebirdtech/engine
that referenced
this issue
Jun 22, 2023
#8) * Bump updater dependency to include fix for shorebirdtech/shorebird#235
felangel
pushed a commit
to shorebirdtech/engine
that referenced
this issue
Jul 13, 2023
* Fix unterminated string causing flaky behavior. Fixes shorebirdtech/shorebird#235 The root cause was we were not terminating the strings passed for original_libapp_paths. We used a Vector<char> but didn't append a '\0' to the end before calling data(), so when the c/rust side walked to find the end of the char* it sometimes found extra characters at the end of the string unexpectedly. This fixes to use a shorter (but probably equally dangerous?) method of using c_str() which we had tried before but previously had used c_str() on a temporary. This attempt carefully uses a reference to the string so the c_str()'s lifetime is tied to the string in application_library_paths rather than a temporary copy. This is still slightly dangerous in that c_str() lives as long as a std::string does, so long as it's not modified. * Fix comments
felangel
pushed a commit
to shorebirdtech/engine
that referenced
this issue
Jul 13, 2023
#8) * Bump updater dependency to include fix for shorebirdtech/shorebird#235
felangel
pushed a commit
to shorebirdtech/engine
that referenced
this issue
Aug 18, 2023
* Fix unterminated string causing flaky behavior. Fixes shorebirdtech/shorebird#235 The root cause was we were not terminating the strings passed for original_libapp_paths. We used a Vector<char> but didn't append a '\0' to the end before calling data(), so when the c/rust side walked to find the end of the char* it sometimes found extra characters at the end of the string unexpectedly. This fixes to use a shorter (but probably equally dangerous?) method of using c_str() which we had tried before but previously had used c_str() on a temporary. This attempt carefully uses a reference to the string so the c_str()'s lifetime is tied to the string in application_library_paths rather than a temporary copy. This is still slightly dangerous in that c_str() lives as long as a std::string does, so long as it's not modified. * Fix comments
felangel
pushed a commit
to shorebirdtech/engine
that referenced
this issue
Aug 18, 2023
#8) * Bump updater dependency to include fix for shorebirdtech/shorebird#235
felangel
pushed a commit
to shorebirdtech/engine
that referenced
this issue
Aug 24, 2023
* Fix unterminated string causing flaky behavior. Fixes shorebirdtech/shorebird#235 The root cause was we were not terminating the strings passed for original_libapp_paths. We used a Vector<char> but didn't append a '\0' to the end before calling data(), so when the c/rust side walked to find the end of the char* it sometimes found extra characters at the end of the string unexpectedly. This fixes to use a shorter (but probably equally dangerous?) method of using c_str() which we had tried before but previously had used c_str() on a temporary. This attempt carefully uses a reference to the string so the c_str()'s lifetime is tied to the string in application_library_paths rather than a temporary copy. This is still slightly dangerous in that c_str() lives as long as a std::string does, so long as it's not modified. * Fix comments
felangel
pushed a commit
to shorebirdtech/engine
that referenced
this issue
Aug 24, 2023
#8) * Bump updater dependency to include fix for shorebirdtech/shorebird#235
eseidel
added a commit
to shorebirdtech/engine
that referenced
this issue
Sep 8, 2023
* Fix unterminated string causing flaky behavior. Fixes shorebirdtech/shorebird#235 The root cause was we were not terminating the strings passed for original_libapp_paths. We used a Vector<char> but didn't append a '\0' to the end before calling data(), so when the c/rust side walked to find the end of the char* it sometimes found extra characters at the end of the string unexpectedly. This fixes to use a shorter (but probably equally dangerous?) method of using c_str() which we had tried before but previously had used c_str() on a temporary. This attempt carefully uses a reference to the string so the c_str()'s lifetime is tied to the string in application_library_paths rather than a temporary copy. This is still slightly dangerous in that c_str() lives as long as a std::string does, so long as it's not modified. * Fix comments
eseidel
added a commit
to shorebirdtech/engine
that referenced
this issue
Sep 8, 2023
#8) * Bump updater dependency to include fix for shorebirdtech/shorebird#235
eseidel
added a commit
to shorebirdtech/engine
that referenced
this issue
Sep 19, 2023
* Fix unterminated string causing flaky behavior. Fixes shorebirdtech/shorebird#235 The root cause was we were not terminating the strings passed for original_libapp_paths. We used a Vector<char> but didn't append a '\0' to the end before calling data(), so when the c/rust side walked to find the end of the char* it sometimes found extra characters at the end of the string unexpectedly. This fixes to use a shorter (but probably equally dangerous?) method of using c_str() which we had tried before but previously had used c_str() on a temporary. This attempt carefully uses a reference to the string so the c_str()'s lifetime is tied to the string in application_library_paths rather than a temporary copy. This is still slightly dangerous in that c_str() lives as long as a std::string does, so long as it's not modified. * Fix comments
eseidel
added a commit
to shorebirdtech/engine
that referenced
this issue
Sep 19, 2023
#8) * Bump updater dependency to include fix for shorebirdtech/shorebird#235
eseidel
added a commit
to shorebirdtech/engine
that referenced
this issue
Sep 21, 2023
* Fix unterminated string causing flaky behavior. Fixes shorebirdtech/shorebird#235 The root cause was we were not terminating the strings passed for original_libapp_paths. We used a Vector<char> but didn't append a '\0' to the end before calling data(), so when the c/rust side walked to find the end of the char* it sometimes found extra characters at the end of the string unexpectedly. This fixes to use a shorter (but probably equally dangerous?) method of using c_str() which we had tried before but previously had used c_str() on a temporary. This attempt carefully uses a reference to the string so the c_str()'s lifetime is tied to the string in application_library_paths rather than a temporary copy. This is still slightly dangerous in that c_str() lives as long as a std::string does, so long as it's not modified. * Fix comments
eseidel
added a commit
to shorebirdtech/engine
that referenced
this issue
Sep 21, 2023
#8) * Bump updater dependency to include fix for shorebirdtech/shorebird#235
eseidel
added a commit
to shorebirdtech/engine
that referenced
this issue
Oct 2, 2023
* Fix unterminated string causing flaky behavior. Fixes shorebirdtech/shorebird#235 The root cause was we were not terminating the strings passed for original_libapp_paths. We used a Vector<char> but didn't append a '\0' to the end before calling data(), so when the c/rust side walked to find the end of the char* it sometimes found extra characters at the end of the string unexpectedly. This fixes to use a shorter (but probably equally dangerous?) method of using c_str() which we had tried before but previously had used c_str() on a temporary. This attempt carefully uses a reference to the string so the c_str()'s lifetime is tied to the string in application_library_paths rather than a temporary copy. This is still slightly dangerous in that c_str() lives as long as a std::string does, so long as it's not modified. * Fix comments
eseidel
added a commit
to shorebirdtech/engine
that referenced
this issue
Oct 2, 2023
#8) * Bump updater dependency to include fix for shorebirdtech/shorebird#235
eseidel
added a commit
to shorebirdtech/engine
that referenced
this issue
Oct 19, 2023
* Fix unterminated string causing flaky behavior. Fixes shorebirdtech/shorebird#235 The root cause was we were not terminating the strings passed for original_libapp_paths. We used a Vector<char> but didn't append a '\0' to the end before calling data(), so when the c/rust side walked to find the end of the char* it sometimes found extra characters at the end of the string unexpectedly. This fixes to use a shorter (but probably equally dangerous?) method of using c_str() which we had tried before but previously had used c_str() on a temporary. This attempt carefully uses a reference to the string so the c_str()'s lifetime is tied to the string in application_library_paths rather than a temporary copy. This is still slightly dangerous in that c_str() lives as long as a std::string does, so long as it's not modified. * Fix comments
eseidel
added a commit
to shorebirdtech/engine
that referenced
this issue
Oct 19, 2023
#8) * Bump updater dependency to include fix for shorebirdtech/shorebird#235
felangel
pushed a commit
to shorebirdtech/engine
that referenced
this issue
Oct 26, 2023
* Fix unterminated string causing flaky behavior. Fixes shorebirdtech/shorebird#235 The root cause was we were not terminating the strings passed for original_libapp_paths. We used a Vector<char> but didn't append a '\0' to the end before calling data(), so when the c/rust side walked to find the end of the char* it sometimes found extra characters at the end of the string unexpectedly. This fixes to use a shorter (but probably equally dangerous?) method of using c_str() which we had tried before but previously had used c_str() on a temporary. This attempt carefully uses a reference to the string so the c_str()'s lifetime is tied to the string in application_library_paths rather than a temporary copy. This is still slightly dangerous in that c_str() lives as long as a std::string does, so long as it's not modified. * Fix comments
felangel
pushed a commit
to shorebirdtech/engine
that referenced
this issue
Oct 26, 2023
#8) * Bump updater dependency to include fix for shorebirdtech/shorebird#235
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I don't think we have an issue tracking this yet, so creating one.
This report came in from a trusted tester. It appears that sometimes the libapp.so path given to the engine does not exist on disk. It's probably a synthetic path that Android apis know how to magically extract from the APK and once they've done that later launches have the libapp.so on disk.
This only seems to happen from playstore installs, not from local installs.
@felangel has reproduced it with TimeShift install from the play store.
The text was updated successfully, but these errors were encountered: