I see that, Dart stack trace all ends with 3/7/b/f (ARM architecture), while we know ARM/Thumb/Thumb(2) instructions are 2 or 4 bytes.
example: https://github.com/dart-lang/sdk/issues/43274
Warning: This VM has been configured to produce stack traces that violate the Dart standard.
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 29278, tid: 29340, name 1.ui
isolate_dso_base: 6fe9d64000, vm_dso_base: 6fe9d64000
isolate_instructions: 6fe9d74000, vm_instructions: 6fe9d66000
#00 abs 0000006fe9f4e87b virt 00000000001ea87b _kDartIsolateSnapshotInstructions+0x1da87b
#01 abs 0000006fe9f4e4a3 virt 00000000001ea4a3 _kDartIsolateSnapshotInstructions+0x1da4a3
#02 abs 0000006fe9d83ca3 virt 000000000001fca3 _kDartIsolateSnapshotInstructions+0xfca3
Thus, I wonder how could this happen? IMHO the ARM CPU will run the machine instructions (assembly) in the .so file in Android. But how can the CPU run it if all instructions do not align with 2/4 bytes?
Thanks for any suggestions!
The lsb is the "thumb bit" so to say.
You can switch between ARM and thumb mode with the instruction bx or blx.
These instructions scan the lsb, and if it's set, it will switch to thumb mode and to ARM mode if otherwise. Then branch to address&~1
The stack trace shows the return address of the caller functions, and that they are odd indicates that they are written/compiled in thumb mode.
Related
I am experiencing the below issue with Parallel h5py on MacOS Ventura 13.0.1, on a 2020 MacBook Pro 4-Core Intel Core i7.
I installed h5py and dependencies, by following both of these docs and this guide.
Running a job which requires only mpi4py runs and finishes without any issues. The problem comes when I try to run a job which requires Parallel h5py, e.g. trying out this code.
I get back the following:
*** The MPI_Comm_dup() function was called before MPI_INIT was invoked.
*** This is disallowed by the MPI standard.
*** Your MPI job will now abort.
[...] Local abort before MPI_INIT completed completed successfully, but am not able to aggregate error messages, and not able to guarantee that all other processes were killed!
*** The MPI_Comm_dup() function was called before MPI_INIT was invoked.
*** This is disallowed by the MPI standard.
*** Your MPI job will now abort.
[...] Local abort before MPI_INIT completed completed successfully, but am not able to aggregate error messages, and not able to guarantee that all other processes were killed!
*** The MPI_Comm_dup() function was called before MPI_INIT was invoked.
*** This is disallowed by the MPI standard.
*** Your MPI job will now abort.
[...] Local abort before MPI_INIT completed completed successfully, but am not able to aggregate error messages, and not able to guarantee that all other processes were killed!
*** The MPI_Comm_dup() function was called before MPI_INIT was invoked.
*** This is disallowed by the MPI standard.
*** Your MPI job will now abort.
[...] Local abort before MPI_INIT completed completed successfully, but am not able to aggregate error messages, and not able to guarantee that all other processes were killed!
--------------------------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpiexec detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:
Process name: [[20469,1],3]
Exit code: 1
--------------------------------------------------------------------------
I found this GitHub issue, but it didn't help in my case.
I should also point out that I managed to install and use Parallel h5py on a MacBook Air with MacOS Monterey, though that one is only dual-core, so it doesn't allow me to test Parallel h5py with as many cores, without using -overcommit.
Since I have not found any ideas how to resolve this, apart from the above GitHub issue, I would appreciate any suggestions.
I have developed a flutter app, signed and built an app bundle. I have included the following lines in the app/build.gradle stating that:
android {
compileSdkVersion 32
ndkPath = "/Users/mmm/Library/Android/sdk/ndk/24.0.8215888"
...
defaultConfig {
applicationId "com.blablabla.my_app"
minSdkVersion 21
targetSdkVersion 32
versionCode flutterVersionCode.toInteger()
versionName flutterVersionName
ndk {
abiFilters 'armeabi-v7a', 'arm64-v8a', 'x86_64'
}
}
...
buildTypes {
release {
// TODO: Add your own signing config for the release build.
// Signing with the debug keys for now, so `flutter run --release` works.
signingConfig signingConfigs.release
shrinkResources false
minifyEnabled false
}
}
}
android.buildTypes.release.ndk.debugSymbolLevel = 'symbol_table'
When I publish that app to Closed Beta testing, it keeps saying there is a Native Crash while tested on a GCE x86 emulator. I even tried not including the 'x86_64' abi but the Play Store Console still put the app on that GCE phone to test. The video shows my app's Home page appear for less than a second then disappears. I only knew dart and flutter and the crash report keeps saying something I have absolutely do not understand:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'generic/gce_x86_phone/gce_x86:9/PGR1.190916.001/5877764:userdebug/test-keys'
Revision: '0'
ABI: 'x86'
pid: 6487, tid: 7424, name: 1.raster >>> com.blablabla.my_app <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'vendor/unbundled_google/libs/ndk_translation/ndk_translation/ir/include/ndk_translation/ir/ir.h:685: CHECK failed: IsAligned(offset, GetFormatSize(format))'
eax 00000000 ebx 00001957 ecx 00001d00 edx 00000006
edi 00001957 esi ca3bfb5c
ebp ca3bfb28 esp ca3bfab8 eip f10a2be9
backtrace:
#00 pc 00000be9 [vdso:f10a2000] (__kernel_vsyscall+9)
#01 pc 0001fdf8 /system/lib/libc.so (syscall+40)
#02 pc 00022e73 /system/lib/libc.so (abort+115)
#03 pc 00006c84 /system/lib/liblog.so (__android_log_assert+292)
#04 pc 0009f2b4 /system/lib/libndk_translation.so (ndk_translation::GetInsn::GetInsn(ndk_translation::IR*, ndk_translation::Format, unsigned int)+276)
#05 pc 0009f100 /system/lib/libndk_translation.so (ndk_translation::IRBuilder::Get(ndk_translation::Format, unsigned int)+144)
#06 pc 0009dd2e /system/lib/libndk_translation.so (ndk_translation::(anonymous namespace)::InsnBuilder::Get(ndk_translation::Format, unsigned int)+46)
#07 pc 000d0b4b /system/lib/libndk_translation.so (ndk_translation::SemanticsDecoder::VTBL(ndk_translation::VTBL_Args const&)+363)
#08 pc 00100568 /system/lib/libndk_translation.so (ndk_translation::ArmDecoder::TranslateThumbInsn(unsigned short const*)+86104)
#09 pc 0009c2b6 /system/lib/libndk_translation.so (ndk_translation::(anonymous namespace)::GenerateIRHelper(ndk_translation::CompilerHooks*, unsigned int, unsigned int, ndk_translation::IR*)+1142)
#10 pc 0009be1f /system/lib/libndk_translation.so (ndk_translation::GenerateIR(ndk_translation::CompilerHooks*, unsigned int, ndk_translation::IR*, unsigned int*)+47)
#11 pc 0009bbdf /system/lib/libndk_translation.so (ndk_translation::Compile(ndk_translation::CompilerHooks*, unsigned int, ndk_translation::GuestCodeEntry*, unsigned int*, ndk_translation::MachineCode*)+143)
#12 pc 0007a0da /system/lib/libndk_translation.so (ndk_translation::(anonymous namespace)::Translate(ndk_translation::TranslationCache*, unsigned int, ndk_translation::GuestCodeEntry*)+378)
#13 pc 00079f1c /system/lib/libndk_translation.so (ndk_translation_HandleNotTranslated+300)
#14 pc 0018db57 /system/lib/libndk_translation.so
As my app is using bluetooth, I tried a checking method before runApp() to avoid the emulator attempting to run any part that's related to flutter_blue_plus. But that did not help.
I already tried different measures for 10 times, still getting this crash report. I even put the app to production launch, but the console blocks that and put my app to "reviewing".
Then, I upgraded to the newest Flutter 3.0.2 and created a new FLUTTER SAMPLE STARTER PROJECT (that plain old counter one!), signed for release and put onto Play Store Closed Beta, the above crash still happens!
flutter cleaned every time before I build the app, nothing helps!
I am developing on a Macbook Pro M1 2020 version, with Android Studio Chipmunk 2021.2.1 Patch 1 (built on May 19, 2022).
Is there any settings I can make so the Play Store Console skip testing on that GCE x86 phone? I have googled that and it is Google Computing Engine one, it is not shown in the device catalog. All Intel chips, x86 phones and the Google x86 Emulator(I think this is not the GCE one) are excluded from the testing.
Please help! I have been working on this flutter app for over a year. Manual installation on physical devices works fine. I feel very frustrated, anxious and lost, my bosses are giving me very high pressure. I must get it on to the Play Store in 1 week. HELP!
EVEN A PLAIN FLUTTER STARTER PROJECT CRASHES
Crash Report
I am using a third-party C++ app, which owing to some bug occasionally spews out a double free or corruption error. The error does not prevent the app from functioning normally and I do not have desire to debug third-party apps. Therefore, I just lived with the occasional messages. However, after updating Ubuntu from 14.04 to 16.04 the one-line error messages became pages of annoying text in my terminal, like:
*** Error in `/usr/bin/~': double free or corruption (!prev): 0x000055eebccb43d0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f78579047e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x7fe0a)[0x7f785790ce0a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f785791098c]
/usr/lib/x86_64-linux-gnu/lib~.so.6(Nlm_MemFree+0xe)[0x7f7857e9381e]
/usr/lib/x86_64-linux-gnu/lib~.so.6(ReleaseAppErrInfo+0xb3)[0x7f7857e8e4b3]
/usr/lib/x86_64-linux-gnu/lib~.so.6(Nlm_ReleaseAppContext+0x56)[0x7f7857e91ae6]
/usr/bin/~(NlmThreadExit+0x73)[0x55eebb7d1513]
/usr/bin/~(+0x85d7)[0x55eebb7d15d7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7f7857c5d6ba]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f785799382d]
======= Memory map: ========
55eebb7c9000-55eebb7d4000 r-xp 00000000 08:01 4334530 /usr/bin/~
~
~
My question: is there a way to disable backtrace and limit the message to just the first line under Ubuntu 16.04?
I'm trying to make an little bash script for automatisation of ipa uploading on itunes. [From Xcode uploading it works fine].
For command:
gym
from Fastlane,some projects are uploading fine, others are failing with log:
The following build commands failed:
GenerateDSYMFile [...]
Exit status: 65
In gym logs:
GenerateDSYMFile [...]
dsymutil(20223,0x7fff724c3000) malloc: *** error for object 0x610000100000: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/dsymutil failed with exit code 6
...tried all google solutions....
I've had the same issue.
I've found a reference in this thread, and also here
suggesting that it's the MallocNanoZone environment variable. after changing it (on terminal):
export MallocNanoZone=0
The build successfully completed.
We have an Orion instance which crashes about once each day or two.
In /var/log/contextBroker/contextBroker-service.out I have found:
log directory: '/var/log/contextBroker'
*** glibc detected *** /usr/bin/contextBroker: corrupted double-linked list: 0x00007f0ed92e3f70 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x75f4e)[0x7f0eecdeaf4e]
/lib64/libc.so.6(+0x763d3)[0x7f0eecdeb3d3]
/lib64/libc.so.6(+0x78c88)[0x7f0eecdedc88]
/usr/lib64/libstdc++.so.6(_ZNSsD1Ev+0x39)[0x7f0eed6404c9]
/usr/bin/contextBroker(_Z9jsonParseP14ConnectionInfoPKcRKSsP8JsonNodeP9ParseData+0x539)[0x56fb99]
/usr/bin/contextBroker(_Z9jsonTreatPKcP14ConnectionInfoP9ParseData11RequestTypeRKSsPP11JsonRequest+0x17d)[0x56cf0d]
/usr/bin/contextBroker(_Z12payloadParseP14ConnectionInfoP9ParseDataP11RestServicePP10XmlRequestPP11JsonRequestP18JsonDelayedReleaseRSt6vectorISsSaISsEE+0x3f2)[0x564012]
/usr/bin/contextBroker(_Z11restServiceP14ConnectionInfoP11RestService+0x126c)[0x5654bc]
/usr/bin/contextBroker[0x55cbb6]
/usr/bin/contextBroker[0x55f987]
/usr/lib64/libmicrohttpd.so.10(+0x5599)[0x7f0eee1cf599]
/usr/lib64/libmicrohttpd.so.10(MHD_connection_handle_idle+0x518)[0x7f0eee1d0078]
/usr/lib64/libmicrohttpd.so.10(+0xc3c8)[0x7f0eee1d63c8]
/lib64/libpthread.so.0(+0x7a51)[0x7f0eec957a51]
/lib64/libc.so.6(clone+0x6d)[0x7f0eece5d93d]
And in /var/log/contextBroker/contextBroker-service.out.old the following:
log directory: '/var/log/contextBroker'
*** glibc detected *** /usr/bin/contextBroker: free(): invalid next size (fast): 0x00007fe6d4262110 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x75f4e)[0x7fe6e8e9cf4e]
/lib64/libc.so.6(+0x78cf0)[0x7fe6e8e9fcf0]
/usr/bin/contextBroker(_ZN20ContextElementVector7releaseEv+0x2fa)[0x5f4a4a]
/usr/bin/contextBroker(_Z17postUpdateContextP14ConnectionInfoiRSt6vectorISsSaISsEEP9ParseDatab+0x1472)[0x4d6692]
/usr/bin/contextBroker(_Z11restServiceP14ConnectionInfoP11RestService+0x6d6)[0x564926]
/usr/bin/contextBroker[0x55cbb6]
/usr/bin/contextBroker[0x55f987]
/usr/lib64/libmicrohttpd.so.10(+0x5599)[0x7fe6ea281599]
/usr/lib64/libmicrohttpd.so.10(MHD_connection_handle_idle+0x518)[0x7fe6ea282078]
/usr/lib64/libmicrohttpd.so.10(+0xc3c8)[0x7fe6ea2883c8]
/lib64/libpthread.so.0(+0x7a51)[0x7fe6e8a09a51]
/lib64/libc.so.6(clone+0x6d)[0x7fe6e8f0f93d]
Data is sent to the Orion in batches each 5 minutes:
a request with around 500 contextElements
a request with around 10 contextElements
a request with a single contextElements
Orion has only 2 subscriptions (AFAIK) which send the data to Proton-CEP.
The Orion version is:
[centos#orion ~]$ /usr/bin/contextBroker --version
0.25.0 (git version: a8cf800d4e9fdd7b4293a886490c40309a5bb58c)
Copyright 2013-2015 Telefonica Investigacion y Desarrollo, S.A.U
Is there anything we can do to debug the issue?
Taking into account user inputs, Orion seems to be running below the recommended CPU and RAM thresholds (see recomendations). Thus, probably with more resources (e.g. 2 vCPU and 4GM RAM) it run better, specially if MongoDB runs in the same machine that Orion (MongoDB is known to be a memory-intensive process).