Re: SalAbort:Unspecified application error

[Michael Weghorn]

On 30/04/2022 06.14, di liu wrote:
I am so sorry,I made a mistake (I made some local changes but did not 
restore the code completely which interferes the test result.)

After my initial test(on the same devices) the crash disappeared.
I will continue to test this issue on different devices and scenarios to 
make sure it be fixed completely


Great, thanks for the update.


  Yeah,thank you so much for all you do.


Thank you for your valuable input. :-)


OpenPGP_signature
Description: OpenPGP digital signature

Re: SalAbort:Unspecified application error

[di liu]

>
> I have created a separate ticket in Bugzilla for that one and added some
> more information, also mentioning a potential workaround:
> https://bugs.documentfoundation.org/show_bug.cgi?id=148854
>
> I suggest to continue discussion about that particular issue in Bugzilla
> (e.g. I'd be interested whether your crash also disappears when you do
> that change locally).
>

Ok,I will post the follow-up questions here

Michael Weghorn  于2022年4月29日周五 23:39写道：

>
> On 29/04/2022 12.54, Michael Weghorn wrote:
> >> 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)
> >
> > Great, thanks.
>
> I've now created a Bugzilla ticket for the initial issue that I could
> reproduce and have a pending fix for that in Gerrit:
> https://bugs.documentfoundation.org/show_bug.cgi?id=148851
> https://gerrit.libreoffice.org/c/core/+/133581
>
> With that in place, I didn't see any more crashes or unexpected memory
> usage increase when testing more with your sample doc and experimental
> mode *disabled*.
>
> I can still reproduce a crash due to running out of memory with
> experimental mode *enabled*, though.
>
> I have created a separate ticket in Bugzilla for that one and added some
> more information, also mentioning a potential workaround:
> https://bugs.documentfoundation.org/show_bug.cgi?id=148854
>
> I suggest to continue discussion about that particular issue in Bugzilla
> (e.g. I'd be interested whether your crash also disappears when you do
> that change locally).
>
> >  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")
>
> 4 GB are actually not much. I have no further ideas what you could
> do/try to do a build with debug symbols in that setup, other than having
> lots of swap, which will probably be very slow.
>

Re: SalAbort:Unspecified application error

[di liu]

>
> Does "more times" here mean that it takes longer now than previously
> until the problem shows up? Or is it pretty much unchanged for you?
>
> Is that with experimental mode enabled or disabled in the app settings?
>

I am so sorry,I made a mistake (I made some local changes but did not
restore the code completely which interferes the test result.)
After my initial test(on the same devices) the crash disappeared.
I will continue to test this issue on different devices and scenarios to
make sure it be fixed completely

Yes, that's most likely.
> The one from https://gerrit.libreoffice.org/c/core/+/133581 is also
> called further down in the stack from there and was clearly showing up
> in the memory profile.
>
> The app was working fine with the sample file in non-editing mode  for
> me with that hack in place in a quick test.
> But it's well possible that there are more leaks elsewhere.
>


 Yeah,thank you so much for all you do.

Michael Weghorn  于2022年4月29日周五 18:54写道：

> > 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)
>
> Great, thanks.
>
>
> On 29/04/2022 12.07, di liu wrote:
> > 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.
>
> Does "more times" here mean that it takes longer now than previously
> until the problem shows up? Or is it pretty much unchanged for you?
>
> Is that with experimental mode enabled or disabled in the app settings?
>
> > 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
>
> Yes, that's most likely.
> The one from https://gerrit.libreoffice.org/c/core/+/133581 is also
> called further down in the stack from there and was clearly showing up
> in the memory profile.
>
> The app was working fine with the sample file in non-editing mode  for
> me with that hack in place in a quick test.
> But it's well possible that there are more leaks elsewhere.
>

Re: SalAbort:Unspecified application error

[Michael Weghorn]

On 29/04/2022 12.54, Michael Weghorn wrote:

    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)


Great, thanks.


I've now created a Bugzilla ticket for the initial issue that I could 
reproduce and have a pending fix for that in Gerrit:

https://bugs.documentfoundation.org/show_bug.cgi?id=148851
https://gerrit.libreoffice.org/c/core/+/133581

With that in place, I didn't see any more crashes or unexpected memory 
usage increase when testing more with your sample doc and experimental 
mode *disabled*.


I can still reproduce a crash due to running out of memory with 
experimental mode *enabled*, though.


I have created a separate ticket in Bugzilla for that one and added some 
more information, also mentioning a potential workaround:

https://bugs.documentfoundation.org/show_bug.cgi?id=148854

I suggest to continue discussion about that particular issue in Bugzilla 
(e.g. I'd be interested whether your crash also disappears when you do 
that change locally).



 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")


4 GB are actually not much. I have no further ideas what you could 
do/try to do a build with debug symbols in that setup, other than having 
lots of swap, which will probably be very slow.

Re: SalAbort:Unspecified application error

[Michael Weghorn]

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)


Great, thanks.


On 29/04/2022 12.07, di liu wrote:

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.


Does "more times" here mean that it takes longer now than previously 
until the problem shows up? Or is it pretty much unchanged for you?


Is that with experimental mode enabled or disabled in the app settings?

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


Yes, that's most likely.
The one from https://gerrit.libreoffice.org/c/core/+/133581 is also 
called further down in the stack from there and was clearly showing up 
in the memory profile.


The app was working fine with the sample file in non-editing mode  for 
me with that hack in place in a quick test.

But it's well possible that there are more leaks elsewhere.

Re: SalAbort:Unspecified application error

[di liu]

>
> 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  于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  于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
>> > 
>> >
>> > 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'
>> >
>> >
>> > 

Re: SalAbort:Unspecified application error

[di liu]

>
> 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  于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
> > 
> >
> > 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 

Re: SalAbort:Unspecified application error

[Michael Weghorn]

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


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.

Re: SalAbort:Unspecified application error

[Michael Weghorn]

On 27/04/2022 17.27, Michael Weghorn wrote:
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

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/


... which is obviously using NDK 21.0.6113669, not 22.1.7171670 (which 
is mentioned in the Gerrit patch, but that was for another discussion...).

Re: SalAbort:Unspecified application error

[Michael Weghorn]

On 27/04/2022 09.34, di liu wrote:

forget the crash video add it
crash_video.mp4 



The video appears to be inaccessible unless access has specifically been 
granted in Google Drive.


di liu mailto:disco@gmail.com>> 于2022年4月27 
日周三 15:23写道：

There has  a crash error when i use libreoffice in android which is
compiled from the source code.

*The development information:*
the libreoffice branch is *master*(update when a write this mail)
*phone information:*
android sdk : *29(android 10)*
brand*:**HUAWEI HMI-AL100*
ram*:6G*
screen*:2244x1080*


Does that device have a 64-bit ARM processor?


*The triggering scenario for this error：*
This error appears more frequently  when load xlsx file(load other
file also happen).
when l load xlsx file and zoom in the document then slide up and
down quickly (the video in the accessorias) the app will be crashed
suddenly.


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",...)?
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.



the full error log is below

[...]
*What i have try:*
I think the key point log is
org.free.dike.ldoffice E/LibreOffice/androidinst: SalAbort:
'Unspecified application error'
so i searched this message in the source code and finally found it's
in this method: "vcl/source/app/salplug.cxx -> void SalAbort( const
OUString& rErrorText, bool bDumpCore )"
And i search the method 'SalAbort'  to found out the possible invoke
chains.But when i reached method "void
Desktop::Exception(ExceptionCategory nCategory)" in
"desktop/source/app/app.cxx" which i think is most possibly invoke
point trigger this crash. But unfortunately i have not found who
invoke this method. I want to use gdb to debug but when i try to
compile a new so which contain needed symbols and debug info i meet
a link error again(clang++ error:unable to execute command Killed)
which i think cause by low memory of my computer,But i can't change
it...


Finding a working combination of NDK version and linker that work for a 
specific architecture and debug configuration can be a bit tricky.


What does your autogen.input look like? (Or what options are you passing 
to ./autogen.sh manually?)


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

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/

(Maybe requiring newer NDK versions and switching to LLD for all 
architectures might work by now, but that would need some more testing. 
At least this didn't work for all architectures with older NDK versions 
~2 years ago.)



So could you give me some suggestions how to solve this error


In addition to the above, you could try whether it crashes the same way 
with a daily build provided by TDF, available here, to see whether it's 
in some way related to your build setup:

https://dev-builds.libreoffice.org/daily/master/current.html

Re: SalAbort:Unspecified application error

[di liu]

forget the crash video add it
 crash_video.mp4


di liu  于2022年4月27日周三 15:23写道：

> Hi,
> There has  a crash error when i use libreoffice in android which is
> compiled from the source code.
>
> *The development information:*
> the libreoffice branch is *master*(update when a write this mail)
> *phone information:*
> android sdk : *29(android 10)*
> brand*:**HUAWEI HMI-AL100*
> ram*:6G*
> screen*:2244x1080*
>
> *The triggering scenario for this error：*
> This error appears more frequently  when load xlsx file(load other file
> also happen).
> when l load xlsx file and zoom in the document then slide up and down
> quickly (the video in the accessorias) the app will be crashed suddenly.
>
> the full error log is below
>
> 2022-04-27 14:17:46.736 1523-2407/? E/ProcessInfoCollector:
> getProcessInfo: failed to find this proc.
> 2022-04-27 14:17:46.748 27142-27142/? E/.huawei.hitouc: Not starting
> debugger since process cannot load the jdwp agent.
> 2022-04-27 14:17:46.837 27142-27142/? E/MLInitializerProvider:
> MLInitializerProvider Done
> 2022-04-27 14:17:46.903 27142-27158/? E/TouchPolicyHelper: activity is
> empty.
> 2022-04-27 14:17:46.949 1073-1436/? E/ScreemCommon: fail to extract lcd
> fps mode!
> 2022-04-27 14:17:51.488 1037-1037/? E/Thermal-daemon:hw_thermal: [rfboard]
> tempNew :27  tempOld :26
> 2022-04-27 14:17:51.488 1037-1037/? E/Thermal-daemon:hw_thermal: Report
> temperature: [rfboard] temp :27  reportThreshold:1
> 2022-04-27 14:17:51.490 1037-1037/? E/Thermal-daemon:hw_thermal: [ap]
> tempNew :30  tempOld :29
> 2022-04-27 14:17:51.491 1037-1037/? E/Thermal-daemon:hw_thermal: Report
> temperature: [ap] temp :30  reportThreshold:1
> 2022-04-27 14:17:52.233 1037-4076/? E/Thermal-daemon:ambient:
> UpdateAmbientInformation: devCurrent 519, last_avg_current -332, clear
> history input array
> 2022-04-27 14:17:56.034 2524-3150/? E/DeviceMonitorPowerKit: not Satify
> ApplyResource
> 2022-04-27 14:17:56.492 1037-1037/? E/Thermal-daemon:hw_thermal:
> [charger_ic] tempNew :29  tempOld :28
> 2022-04-27 14:17:56.492 1037-1037/? E/Thermal-daemon:hw_thermal: Report
> temperature: [charger_ic] temp :29  reportThreshold:1
> 2022-04-27 14:17:57.235 1037-4076/? E/Thermal-daemon:ambient:
> UpdateAmbientInformation: is first history!!
> 2022-04-27 14:18:00.015 2288-2288/? E/DateView: DateView,mCurrentTime:
> 1651040280015
> 2022-04-27 14:18:00.060 2288-2288/? E/ndroid.systemu: No package ID ff
> found for ID 0x.
> 2022-04-27 14:18:00.066 2288-2288/? E/ndroid.systemu: No package ID ff
> found for ID 0x.
> 2022-04-27 14:18:01.495 1037-1037/? E/Thermal-daemon:hw_thermal: [ap]
> tempNew :31  tempOld :30
> 2022-04-27 14:18:01.496 1037-1037/? E/Thermal-daemon:hw_thermal: Report
> temperature: [ap] temp :31  reportThreshold:1
> 2022-04-27 14:18:02.239 1037-4076/? E/Thermal-daemon:ambient:
> UpdateAmbientInformation: devCurrent -192, last_avg_current 509, clear
> history input array
> 2022-04-27 14:18:06.499 1037-1037/? E/Thermal-daemon:hw_thermal: [ap]
> tempNew :30  tempOld :31
> 2022-04-27 14:18:06.500 1037-1037/? E/Thermal-daemon:hw_thermal: Report
> temperature: [ap] temp :30  reportThreshold:1
> 2022-04-27 14:18:07.243 1037-4076/? E/Thermal-daemon:ambient:
> UpdateAmbientInformation: is first history!!
> 2022-04-27 14:18:11.500 1037-1037/? E/Thermal-daemon:hw_thermal:
> [shell_frame] tempNew :29  tempOld :28
> 2022-04-27 14:18:11.501 1037-1037/? E/Thermal-daemon:hw_thermal: Report
> temperature: [shell_frame] temp :29  reportThreshold:1
> 2022-04-27 14:18:12.247 1037-4076/? E/Thermal-daemon:ambient:
> UpdateAmbientInformation: devCurrent 488, last_avg_current -164, clear
> history input array
> 2022-04-27 14:18:12.770 1523-2109/? E/WifiConnectivityManager:
> isWifiScanSpecialChannels is false,mWifiState : 2
> 2022-04-27 14:18:12.790 2561-3446/? E/AppInfoMgr: not find pkgs by uid:
> 1010
> 2022-04-27 14:18:14.134 15441-17199/org.free.dike.ldoffice
> E/LibreOffice/androidinst: SalAbort: 'Unspecified application error'
> 2022-04-27 14:18:14.202 1523-2109/? E/SupplicantStaNetworkHal:
> createHalCallback is called !
> 2022-04-27 14:18:14.241 17732-17732/? E/wpa_supplicant: wlan0:
> ssid->assoc_retry=0
> 2022-04-27 14:18:14.241 17732-17732/? E/wpa_supplicant:
> wpas_vendor_send_abs_cmd_to_driver: abs is not enabled
> 2022-04-27 14:18:14.248 1523-1523/? E/HwWifiStateMachine_PAC: unknown state
> 2022-04-27 14:18:14.264 1523-17185/? E/WifiPermissionsUtil:
> getUidPermission is DENIED and permissionType
> android.permission.ACCESS_FINE_LOCATIONuid 1002
> 2022-04-27 14:18:14.264 1523-17185/? E/WifiService:
> enforceCanAccessScanResults: hiding ssid and bssidUID 1002 has no location
> permission
> 2022-04-27 14:18:14.271 2503-2799/? E/NcDftImpl: NcChipDftEvent igonred
> eventId:NcChipDftEvent{Id=1180420, Length=0, Flag=1}total:1631
> 2022-04-27 14:18:14.273 1523-2196/? E/SupplicantStaIfaceHal:
>