Bug 127781 - Crash in documentLoadNative method in a library compiled for arm64-v8a
Summary: Crash in documentLoadNative method in a library compiled for arm64-v8a
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Android Viewer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other Android
: medium normal
Assignee: Michael Weghorn
URL:
Whiteboard: target:7.0.0
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-26 10:48 UTC by ilnur
Modified: 2024-06-20 14:27 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
logcat_libc_crash (10.42 KB, text/plain)
2019-09-26 10:49 UTC, ilnur
Details
logcat_libc_crash_more_detailed (17.59 KB, text/plain)
2019-09-26 10:50 UTC, ilnur
Details
sample doc (8.60 KB, application/vnd.oasis.opendocument.text)
2020-03-06 14:10 UTC, Michael Weghorn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ilnur 2019-09-26 10:48:10 UTC
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:
Comment 1 ilnur 2019-09-26 10:49:15 UTC
Created attachment 154536 [details]
logcat_libc_crash
Comment 2 ilnur 2019-09-26 10:50:31 UTC
Created attachment 154537 [details]
logcat_libc_crash_more_detailed
Comment 3 Xisco Faulí 2019-10-21 11:46:10 UTC
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
Comment 4 ilnur 2019-10-21 11:54:20 UTC
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
Comment 5 Uriy 2019-11-07 10:33:01 UTC
I have same problem
Comment 6 Xisco Faulí 2019-11-07 14:20:45 UTC
I believe, the root cause is the same as in bug 123290

*** This bug has been marked as a duplicate of bug 123290 ***
Comment 7 ilnur 2020-02-13 17:44:15 UTC
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.
Comment 8 Michael Weghorn 2020-03-05 16:12:46 UTC
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
Comment 9 Michael Weghorn 2020-03-05 16:16:59 UTC
(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.)
Comment 10 Commit Notification 2020-03-05 19:18:48 UTC
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.
Comment 11 Michael Weghorn 2020-03-05 19:20:52 UTC
Closing as fixed.

@ilnur: Please leave a comment and reopen in case you should still have any issues.
Comment 12 ilnur 2020-03-06 11:01:35 UTC
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
Comment 13 Michael Weghorn 2020-03-06 14:10:53 UTC
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?
Comment 14 ilnur 2020-03-06 14:51:50 UTC
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.
Comment 15 Michael Weghorn 2020-03-06 16:06:44 UTC
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
Comment 16 ilnur 2020-03-06 16:38:31 UTC
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
Comment 17 Michael Weghorn 2020-03-06 22:56:31 UTC
(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
Comment 18 Michael Weghorn 2020-03-07 03:10:51 UTC
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.
Comment 19 ilnur 2020-03-07 07:53:38 UTC
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).
Comment 20 Michael Weghorn 2020-03-07 09:35:51 UTC
(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.
Comment 21 ilnur 2020-03-10 06:32:45 UTC
(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.
Comment 22 Michael Weghorn 2020-03-11 06:45:45 UTC
(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.
Comment 23 ilnur 2020-03-11 07:42:03 UTC
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.
Comment 24 ilnur 2020-03-11 08:00:54 UTC
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?
Comment 25 Michael Weghorn 2020-03-11 09:24:05 UTC
(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/
Comment 26 Michael Weghorn 2020-03-11 09:32:16 UTC
(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...
Comment 27 Michael Weghorn 2020-04-06 08:41:46 UTC
@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.
Comment 28 ilnur 2020-04-06 08:50:47 UTC
@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.
Comment 29 Michael Weghorn 2020-04-06 09:19:50 UTC
(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.
Comment 30 ilnur 2020-04-10 13:04:03 UTC
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.
Comment 31 Xisco Faulí 2020-04-14 18:13:25 UTC
Setting to VERIFIED based on comment 30

@Michael W., thanks for fixing this issue!
Comment 32 nunezelmer 2024-06-20 14:03:27 UTC Comment hidden (spam)