Open kiber-io opened 1 year ago
Capture logcat
dump after triggering error and post or email.
Capture
logcat
dump after triggering error and post or email.
yes, I was figuring out how to attach a file here (I didn't find 0.0).
here is a gist with a report from termux.
The error is searched by line "JNI DETECTED ERROR IN APPLICATION"
Here is a report with Log level: verbose.
I think I found the problem :D
during the objection work, a file was created in home with the name '$'\001\240''c,@f-@8
.
judging by the log, he breaks everything.
UPD. This is not the original file name. apparently, some unicode characters are used there, which break the work of documentsui. perhaps this is not a termux problem, but an android bug.
@kiber-io sometimes when I terminate apktool in the middle of a process or it breaks for aapt it generates that file similar to the one you showed.
@Anonymous2716, yes, in my case, an unexpected shutdown of apktool also occurred. Here the question is, on whose side is the bug regarding the processing of such names
The error occured in ART (Android Runtime) which runs the applications.
I doubt it is possible to fix it on Termux side as basically issue occurs when java.io.File.listFiles
encounters a file with name containing invalid UTF-8 unless Termux will use own implementation of listFiles()
(possibly in native code). In general, this is not only issue which may happen when file name is constructed of random bytes. Here is another one with worse consequences: https://github.com/termux/termux-app/issues/3228
In next version, rewritten document provider will use java.io.File.listFiles()
for Android < 8
and java.nio.file.Files.walk()
for Android >= 8
, the latter doesn't use JNU_NewStringPlatform/NewStringUTF
in native code while returning file names, and so will not crash the app for Android >= 8
. Have tested with touch 'bitgii asuu '$'\325\352\275\332\371\253\265\352\346''@'$'\265''إթ'$'\342''զ'$'\366''.flac'
in /sdcard/testdir
. However, deleting a directory with that file would still fail with DirectoryNotEmptyException
as expected. Will look into fixing it for older versions if I do backports for nio
for it or use desugar_jdk_libs_nio
, although might not due to unsupported apis unless thoroughly tested. Thanks for the report!
java_vm_ext.cc:594] JNI DETECTED ERROR IN APPLICATION: input is not valid Modified UTF-8: illegal start byte 0xa0
java_vm_ext.cc:594] string: '�c,@f-@8'
java_vm_ext.cc:594] input: '0x01 <0xa0> 0x63 0x2c 0x40 0x66 0x2d 0x40 0x38'
java_vm_ext.cc:594] in call to NewStringUTF
java_vm_ext.cc:594] from java.lang.String[] java.io.UnixFileSystem.list0(java.io.File)
runtime.cc:676] Runtime aborting...
runtime.cc:676] Dumping all threads without mutator lock held
runtime.cc:676] All threads:
runtime.cc:676] DALVIK THREADS (29):
runtime.cc:676] "binder:24088_7" prio=4 tid=4 Runnable
runtime.cc:676] | group="" sCount=0 ucsCount=0 flags=0 obj=0x13040f08 self=0x7856cde540
runtime.cc:676] | sysTid=24942 nice=10 cgrp=foreground sched=0/0 handle=0x76cbb3ccb0
runtime.cc:676] | state=R schedstat=( 13807971 17269791 55 ) utm=0 stm=0 core=7 HZ=100
runtime.cc:676] | stack=0x76cba45000-0x76cba47000 stackSize=991KB
runtime.cc:676] | held mutexes= "abort lock" "mutator lock"(shared held)
runtime.cc:676] native: #00 pc 0000000000536054 /apex/com.android.art/lib64/libart.so (art::DumpNativeStack(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, int, BacktraceMap*, char const*, art::ArtMethod*, void*, bool)+128) (BuildId: a49c773ef6221a996ecea990e9753caa)
runtime.cc:676] native: #01 pc 00000000006ef5e4 /apex/com.android.art/lib64/libart.so (art::Thread::DumpStack(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, bool, BacktraceMap*, bool) const+236) (BuildId: a49c773ef6221a996ecea990e9753caa)
runtime.cc:676] native: #02 pc 00000000006fce70 /apex/com.android.art/lib64/libart.so (art::DumpCheckpoint::Run(art::Thread*)+208) (BuildId: a49c773ef6221a996ecea990e9753caa)
runtime.cc:676] native: #03 pc 00000000003619dc /apex/com.android.art/lib64/libart.so (art::ThreadList::RunCheckpoint(art::Closure*, art::Closure*)+440) (BuildId: a49c773ef6221a996ecea990e9753caa)
runtime.cc:676] native: #04 pc 00000000006fb610 /apex/com.android.art/lib64/libart.so (art::ThreadList::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, bool)+280) (BuildId: a49c773ef6221a996ecea990e9753caa)
runtime.cc:676] native: #05 pc 00000000006d6678 /apex/com.android.art/lib64/libart.so (art::AbortState::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char> >&) const+212) (BuildId: a49c773ef6221a996ecea990e9753caa)
runtime.cc:676] native: #06 pc 00000000006d1364 /apex/com.android.art/lib64/libart.so (art::Runtime::Abort(char const*)+1016) (BuildId: a49c773ef6221a996ecea990e9753caa)
runtime.cc:676] native: #07 pc 0000000000016ea8 /apex/com.android.art/lib64/libbase.so (android::base::SetAborter(std::__1::function<void (char const*)>&&)::$_3::__invoke(char const*)+80) (BuildId: 420d56eac27a210c92900f3ddb760c86)
runtime.cc:676] native: #08 pc 0000000000016450 /apex/com.android.art/lib64/libbase.so (android::base::LogMessage::~LogMessage()+352) (BuildId: 420d56eac27a210c92900f3ddb760c86)
runtime.cc:676] native: #09 pc 0000000000442a24 /apex/com.android.art/lib64/libart.so (art::JavaVMExt::JniAbort(char const*, char const*)+1612) (BuildId: a49c773ef6221a996ecea990e9753caa)
runtime.cc:676] native: #10 pc 00000000003294f4 /apex/com.android.art/lib64/libart.so (art::JavaVMExt::JniAbortV(char const*, char const*, std::__va_list)+108) (BuildId: a49c773ef6221a996ecea990e9753caa)
runtime.cc:676] native: #11 pc 000000000048927c /apex/com.android.art/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::AbortF(char const*, ...) (.__uniq.99033978352804627313491551960229047428)+144) (BuildId: a49c773ef6221a996ecea990e9753caa)
runtime.cc:676] native: #12 pc 0000000000451004 /apex/com.android.art/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::Check(art::ScopedObjectAccess&, bool, char const*, art::(anonymous namespace)::JniValueType*) (.__uniq.99033978352804627313491551960229047428)+3932) (BuildId: a49c773ef6221a996ecea990e9753caa)
runtime.cc:676] native: #13 pc 00000000005c77f4 /apex/com.android.art/lib64/libart.so (art::(anonymous namespace)::CheckJNI::NewStringUTF(_JNIEnv*, char const*) (.__uniq.99033978352804627313491551960229047428.llvm.9836304948508935827)+192) (BuildId: a49c773ef6221a996ecea990e9753caa)
runtime.cc:676] native: #14 pc 0000000000022430 /apex/com.android.art/lib64/libopenjdk.so (Java_java_io_UnixFileSystem_list0+384) (BuildId: df8df6b1c275e887f918729a4f22136c)
runtime.cc:676] at java.io.UnixFileSystem.list0(Native method)
runtime.cc:676] at java.io.UnixFileSystem.list(UnixFileSystem.java:346)
runtime.cc:676] at java.io.File.list(File.java:1129)
runtime.cc:676] at java.io.File.listFiles(File.java:1214)
runtime.cc:676] at com.termux.filepicker.TermuxDocumentsProvider.queryChildDocuments(TermuxDocumentsProvider.java:93)
runtime.cc:676] at android.provider.DocumentsProvider.queryChildDocuments(DocumentsProvider.java:618)
runtime.cc:676] at android.provider.DocumentsProvider.query(DocumentsProvider.java:935)
runtime.cc:676] at android.content.ContentProvider$Transport.query(ContentProvider.java:290)
runtime.cc:676] at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:107)
runtime.cc:676] at android.os.Binder.execTransactInternal(Binder.java:1316)
runtime.cc:676] at android.os.Binder.execTransact(Binder.java:1280)
...
libc : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 24942 (binder:24088_7), pid 24088 (com.termux)
Build fingerprint: 'samsung/r9qxser/r9q:13/TP1A.220624.014/G990BXXS3EWC4:user/release-keys'
Revision: '10'
Problem description
Then you try to open the termux folder through the standard Files application or another application that allows you to use DocumentsUI, termux fails with an error and does not allow you to get into your folder
Steps to reproduce the behavior.
The last thing I did before catching this error was to install objection (and dependencies to it: openjdk, apk signer, apktool, aapt). After launching the objection work via DocumentsUI fell off.
Up to this point, everything worked fine.
What is the expected behavior?
No response
System information
I will attach the report from termux in the comments