Re: SalAbort:Unspecified application error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux