> > 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....@gmail.com> 于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.wegh...@posteo.de> 于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. >> >
