Description: I have compiled libreoffice/core branch libreoffice-6-3-2 for arm64-v8a arch and when I try to open any document I see the method documentLoadNative has crashed (see attachments). When it's compiled for armeabi-v7a the document opens well. Actual Results: Documents are opened without a crash. Expected Results: Crash when opening any document. Reproducible: Always User Profile Reset: Yes Additional Info:
Created attachment 154536 [details] logcat_libc_crash
Created attachment 154537 [details] logcat_libc_crash_more_detailed
Thank you for reporting the bug. Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Hello, I have took one of the available .apk from link you provided. Particularly, I've took this one: https://dev-builds.libreoffice.org/daily/master/Android-ARM@24-Bytemark-Hosting/2019-10-20_23.35.56/master~2019-10-20_23.35.56_LibreOfficeViewer-strippedUI-debug.apk The problem is that libreoffice native library (liblo-native-code.so) in this apk is built for armeabi-v7a architecture (i.e. with distro-config file LibreOfficeAndroid.conf). And I guess it will be fine, because I didn't had problems with builds for armeabi-v7a. However, the crash I am talking about is happening in native library that is built for arm64-v8a architecture (i.e. with distro-config file LibreOfficeAndroidAarch64.conf) https://github.com/LibreOffice/core/blob/master/distro-configs/LibreOfficeAndroidAarch64.conf
I have same problem
I believe, the root cause is the same as in bug 123290 *** This bug has been marked as a duplicate of bug 123290 ***
Hello, the crash still persists. Apk compiled from master branch with the change https://gerrit.libreoffice.org/c/core/+/88519 crashes when opening any document with the following output: https://gist.github.com/lexboss93/444a5fb15017bbcbf0605caf02e801ad Again, this happens when compiling it for arm64-v8a architecture.
Could reproduce the crash with a 64-bit ARM device I currently have access to. This pending patch in Gerrit fixes the issue for me: [1] (and you need the underlying changes [2] and [3] as well, but those are architecture-independent) [1] https://gerrit.libreoffice.org/c/core/+/90047/1 [2] https://gerrit.libreoffice.org/c/core/+/90020/1 [3] https://gerrit.libreoffice.org/c/core/+/90021/1
(In reply to Michael Weghorn from comment #8) > This pending patch in Gerrit fixes the issue for me: [1] (Apparently, it justs extends the existing workaround for aarch64 to cover the Android Viewer as well.)
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cd6b32ef1f3348ce8e529c5f808b704ff728c240 tdf#127781 Android Viewer: aarch64: Avoid throwing exceptions through bridges It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Closing as fixed. @ilnur: Please leave a comment and reopen in case you should still have any issues.
Hello, I've built the master branch on commit id 98bec94b2f88d0a793f2a5a1a0b7fc59d750168b (Update git submodules), and the produced app still can't view documents. logcat is here https://gist.github.com/lexboss93/1432bbae9ab3a655cc4b9a2af1eda928
Created attachment 158452 [details] sample doc (In reply to ilnur from comment #12) > Hello, I've built the master branch on commit id > 98bec94b2f88d0a793f2a5a1a0b7fc59d750168b (Update git submodules), and the > produced app still can't view documents. > logcat is here > https://gist.github.com/lexboss93/1432bbae9ab3a655cc4b9a2af1eda928 To double-check, I've built from exactly the same commit, but cannot any more, the attached sample doc opens fine for me on an Samsung Galaxy S8. Some questions that might help to narrow this down: 1) Does it work if you build for 32-bit arm from the very same commit? 2) What build options are you using? Mine look like this: --build=x86_64-unknown-linux-gnu --with-android-ndk=/home/michi/Android/Sdk/ndk-bundle --with-android-ndk=/home/michi/Android/Sdk/ndk/20.0.5594570/ --with-android-sdk=/home/michi/Android/Sdk --with-distro=LibreOfficeAndroidAarch64 --enable-sal-log --with-external-tar=/home/michi/development/libreoffice-external --enable-ccache --with-jdk-home=/usr/lib/jvm/java-11-openjdk-amd64/ 3) Did you uninstall and reinstall the app to make sure that no old config/cache files play any role? 4) Does it happen with every file, e.g. also the one I attached?
I've rebuilt the repository again with some new commits pulled. Head is now on 1391b1b3eb3d28c7a606a3f0357eef6ca71267e7 (tdf#125261: move UItest to CppunitTest). And the problem is still there. Answers to your questions: 1) I can check it later, but not soon, maybe some days later. (build takes too much time and weekends start tomorrow). p.s. I didn't had problems with 32-bit builds earlier. 2) My autogen.input file is: --with-distro=LibreOfficeAndroidAarch64 --with-android-sdk=/home/user/Android/Sdk --with-android-ndk=/home/user/Android/android-ndk-r20b --with-jdk-home=/usr/lib/jvm/java-8-openjdk-amd64 and I build the repo with single `make` command. Then I do `cd android/source/` and `make install`. 3) Yes, I did it with `adb uninstall org.example.libreoffice` and this command produced the `Success` message. 4) I guess, yes. It also happens with your attachment.
I've temporarily uploaded my APK built from commit 98bec94b2f88d0a793f2a5a1a0b7fc59d750168b here: [1] Can you check whether this crashes for you as well, so we know whether the problem is at build or run time? (maybe try two or three times if it crashes the first time, since I've seen occasional unrelated crashes, some of which should be fixed on current master) [1] https://nextcloud.documentfoundation.org/s/AQzBARCqe7kD2xG
I've got to home, so I've checked it on another device, but also with aarch64 cpu (lenovo TB-8504X). It's not crashing when I try to open a doc, but it never opens it. And crashes when I tap the Home button on device. Attaching the logcat and screen record: https://gist.github.com/lexboss93/447c43637e2082488b16e36aea53448e https://youtu.be/QaYwOsypsyM
(In reply to ilnur from comment #16) > It's not crashing when I try to open a doc, but it never opens it. And > crashes when I tap the Home button on device. How long did you wait? Fontconfig cache initialization when opening a doc the first time after app installation can take two minutes or more with that build (but should be significantly faster with current master, s. [1]). [1] https://gerrit.libreoffice.org/c/core/+/90095
The issue(In reply to ilnur from comment #16) > Attaching the logcat and screen record: > https://gist.github.com/lexboss93/447c43637e2082488b16e36aea53448e > https://youtu.be/QaYwOsypsyM And at at a quick glance, that logcat output looks like it may be the same as tdf#131195, which was just reported on the mailing list and happens with the 32-bit ARM daily build as well.
Yesterday I did wait it 1 min and 49 seconds. You are right. Today I tried it and the document viewer displays documents well (without long progress ring circling).
(In reply to ilnur from comment #19) > Yesterday I did wait it 1 min and 49 seconds. > You are right. Today I tried it and the document viewer displays documents > well (without long progress ring circling). Now the next interesting question is how it behaves on the device where your own build crashes, so please test that once you have access again and find the time to do so.
(In reply to Michael Weghorn from comment #20) > (In reply to ilnur from comment #19) > > Yesterday I did wait it 1 min and 49 seconds. > > You are right. Today I tried it and the document viewer displays documents > > well (without long progress ring circling). > > Now the next interesting question is how it behaves on the device where your > own build crashes, so please test that once you have access again and find > the time to do so. It runs fine on this device also. I think I have to replicate your build options one by one to see if that would fix the problem.
(In reply to ilnur from comment #21) > It runs fine on this device also. > I think I have to replicate your build options one by one to see if that > would fix the problem. By the way, my build runs on Debian testing. Please report back here whether you could make it work.
I have tried it with one additional build option --build=x86_64-unknown-linux-gnu but with no luck. I am at the same commit as you mentioned (98bec94b2f88d0a793f2a5a1a0b7fc59d750168b). I'll try the next build options. p.s. I am on Debian also (Debian GNU/Linux bullseye/sid) p.p.s When opening some files in an app the error message "Cannot open $filePath: loadComponentFromURL returned an empty reference" appears.
Ok, I've tried it with autogen.input which is close to yours --build=x86_64-unknown-linux-gnu --with-distro=LibreOfficeAndroidAarch64 --with-android-sdk=/home/user/Android/Sdk --with-android-ndk=/home/user/Android/android-ndk-r20b --with-jdk-home=/usr/lib/jvm/java-8-openjdk-amd64 --enable-sal-log --enable-ccache These changes not required full rebuild, so it was quick to rebuild it. And the problem is still there. @Michael Weghorn, have you an idea what to do next?
(In reply to ilnur from comment #24) > Ok, I've tried it with autogen.input which is close to yours > --build=x86_64-unknown-linux-gnu > --with-distro=LibreOfficeAndroidAarch64 > --with-android-sdk=/home/user/Android/Sdk > --with-android-ndk=/home/user/Android/android-ndk-r20b > --with-jdk-home=/usr/lib/jvm/java-8-openjdk-amd64 > --enable-sal-log > --enable-ccache > > These changes not required full rebuild, so it was quick to rebuild it. > And the problem is still there. > > @Michael Weghorn, have you an idea what to do next? Can you retry with a clean build? (In reply to ilnur from comment #23) > p.p.s When opening some files in an app the error message "Cannot open > $filePath: loadComponentFromURL returned an empty reference" appears. I suggest retesting with latest master or a daily build from [1] and create separate bug reports with the "problematic" docs attached if it still happens. [1] https://dev-builds.libreoffice.org/daily/master/Android-ARM@24-Bytemark-Hosting/
(In reply to Michael Weghorn from comment #25) > Can you retry with a clean build? ... and maybe with the exact same build options that I was using (except for paths, of course). The NDK I am using was installed from Android Studio's SDK manager. I don't know whether it's in the end the same as you have, but my experience so far was that changing any component in the build chain (e.g. to another version) can quickly lead to all kinds of "interesting" problems for the Android build...
@ilnur: Any news already? Or should we close this bug report for now, since the initial issue has been fixed? You can always open a new one if your further observations indicate that the problem is on LibreOffice side.
@Michael Weghorn, sorry for a long time without news. It's because priority of that task has been lowered for us. But the last time I tried it was crashing. By the way, I've noticed duplicated with-android-ndk option in your autogen.input file. Also it's hard to download exactly the same ndk build (20.0.5594570) because google offers to download only latest builds. Anyway, I'll try to build it again this week and will attach info to this report.
(In reply to ilnur from comment #28) > @Michael Weghorn, sorry for a long time without news. It's because priority > of that task has been lowered for us. No problem. > By the way, I've noticed > duplicated with-android-ndk option in your autogen.input file. Indeed, thanks for mentioning this. The first one can be dropped, of course. > Also it's > hard to download exactly the same ndk build (20.0.5594570) because google > offers to download only latest builds. When you install it from Android Studio's SDK manager, there are multiple versions available, so that should allow to install the exact same version.
Hello. I've tested it again and this time it worked! The machine I tested on is Ubuntu 18.04.3 (not a virtual one). I did a fresh clone of repo and checked-out the exact commit 98bec94b2f88d0a793f2a5a1a0b7fc59d750168b (Update git submodules). I've used the same build options: --build=x86_64-unknown-linux-gnu --with-android-ndk=/home/lexboss/Android/Sdk/ndk/20.0.5594570/ --with-android-sdk=/home/lexboss/Android/Sdk --with-distro=LibreOfficeAndroidAarch64 --enable-sal-log --with-external-tar=/home/lexboss/Projects/libreoffice-external --enable-ccache --with-jdk-home=/usr/lib/jvm/java-11-openjdk-amd64/ I uninstalled the old application from tablet and did install the freshly built one. As usually it took several minutes when I clicked a document for the first time. Thanks to all contributors of this issue and especially to @Michael Weghorn. I think we can close this now.
Setting to VERIFIED based on comment 30 @Michael W., thanks for fixing this issue!