Ok, I will make a try (recompile the source code will spend me hours... )
Unfortunately it's also crash with same error when i swipe up and down more times.
I suppose the memory leak maybe exit in this method "desktop/source/lib/init.cxx -> doc_paintTile".Because every time i swipe the screen the java code will call this method to paint tile where crash was happened
di liu <disco.liu@xxxxxxxxx> 于2022年4月29日周五 16:06写道：
Is that file confidential or can it be shared publicly (attached to a
Bugzilla ticket)? (I can't read most of the text in it. :-))The file is not confidential and can be shared publicly (haha，The text in it is chiness)so with your config that uses --enable-debug and restricts for what
modules symbols are enabled, even less should be needed.My compile machine only has 4GB RAM so that i must restrict the symbols but even so the memory is also not enough(because of that link error "clang++ error:unable to execute command Killed")Can you try whether the demo patch at
https://gerrit.libreoffice.org/c/core/+/133581 makes the crash go away
for you as well?Ok, I will make a try (recompile the source code will spend me hours... )Michael Weghorn <m.weghorn@xxxxxxxxx> 于2022年4月29日周五 03:06写道：
On 28/04/2022 05.04, di liu wrote:
> Thank you for your response ^_^
>
> The video appears to be inaccessible unless access has specifically been
> granted in Google Drive.
>
> I am sorry, have made it
>
> Does that device have a 64-bit ARM processor?
>
> Yeah ,my device abi is arm64-v8a,And the so is compiled for armeabi-v7a
>
> i.e. the crash is not 100% reproducible? Can you give a rough estimation
> of how often it happens? (like "almost always", "about every third
> time",...)?
>
> almost always
>
> It might also help to share a sample doc (e.g. attaching one to a bug
>
> report on Bugzilla) if it happens more often with specific files.
> see the accessories
Thanks for sharing the video and a sample file. With those, I can
reproduce a crash.
Is that file confidential or can it be shared publicly (attached to a
Bugzilla ticket)? (I can't read most of the text in it. :-))
> What does your autogen.input look like? (Or what options are you passing
> to ./autogen.sh manually?)
>
> passing nothing to ./autogen.sh
> the autogen.input containing this:
> --with-distro=LibreOfficeAndroid
> --with-android-sdk=/home/disco/Documents/dev_env/android_sdk
> --with-android-ndk=/home/disco/Documents/dev_env/android_sdk/ndk/20.1.5948944
> --with-ant-home=/home/disco/Documents/dev_env/apache-ant-1.10.12
> --enable-debug
> --enable-symbols="vcl/source/app/"
>
> For a 64-bit ARM debug build, using LLD with NDK 22.1.7171670 worked for
> me in the past, by applying this change on top of master:
> https://gerrit.libreoffice.org/c/core/+/130947
> <https://gerrit.libreoffice.org/c/core/+/130947>
>
> and then using an autogen.input containing this:
>
> --build=x86_64-unknown-linux-gnu
> --with-android-ndk=/home/michi/Android/Sdk/ndk/21.0.6113669
> --with-android-sdk=/home/michi/Android/Sdk
> --with-distro=LibreOfficeAndroidAarch64
> --enable-sal-log
> --with-external-tar=/home/michi/development/libreoffice-external
> --enable-ccache
> --enable-ld=lld
> --enable-dbgutil
> --with-jdk-home=/usr/lib/jvm/java-11-openjdk-amd64/
>
> If i want to build debug version so must build a 64-bit ?
I suppose, in theory, 32-bit should also work. My practical experience
with the Android toolchain was that several things that should work in
theory didn't work in reality, and trying a different architecture, NDK
version, or linker could give better results.
Trying an x86 or x86_64 AVD might also be worth trying.
A dbgutil build works fine for me on a Debian testing machine with 16 GB
of RAM and an autogen.input containing
--build=x86_64-unknown-linux-gnu
--with-android-ndk=/home/michi/Android/Sdk/ndk/20.0.5594570/
--with-android-sdk=/home/michi/Android/Sdk
--with-distro=LibreOfficeAndroidX86
--enable-sal-log
--enable-ccache
--enable-dbgutil
--with-jdk-home=/usr/lib/jvm/java-11-openjdk-amd64/
so with your config that uses --enable-debug and restricts for what
modules symbols are enabled, even less should be needed.
> Addition:
> Yesterday i use "bugreport" command on my device and found below logs:
>
> 04-27 15:53:50.551 10316 3015 3287 W libc : malloc(2292954)
> failed: returning null pointer
> 04-27 15:53:50.552 1000 2433 6251 I chatty : uid=1000(system)
> Binder:2433_6 expire 4 lines
> 04-27 15:53:50.553 10316 3015 3287 E LibreOffice/androidinst:
> SalAbort: 'Unspecified application error'
>
>
> There have a log "malloc(2292954) failed: returning null pointer" before
> the error 'Unspecified application error' (both of them come from my
> app(pid=10316))
> So i wonder if it is possible that the crash was happened in java ?
> Because i found every time i slide the screen it's will trigger the
> render redraw which will trigger allocate a direct buffer
From what I have seen so far, the problem is that the app/system is
running out of memory, caused by a memory leak on the C++ side.
Can you try whether the demo patch at
https://gerrit.libreoffice.org/c/core/+/133581 makes the crash go away
for you as well?
At least with the experimental editing mode disabled, this worked here.
I haven't tried with experimental mode enabled yet, which was running
out of memory earlier without the patch in place, and was showing
another out-of-memory-related error in the ADB log ouput with an x86
debug build.
(The patch is obviously not meant to be merged as is, just a demo where
the problem is.)
PS: Adding dev list back to the conversation.
