I have custom ESP32WROOM based hardware and a mobile app that communicate using Bluetooth Classic via the BluetoothSerial library in Arduino. Everything works great on a wide variety of test devices except for ONE customer who is using a C5L Max with Android 11.
I have verified that this phone works up until its most recent system update. After the update, the moment the app connects to the ESP32, it kernel panics:
Core 0 register dump:
PC : 0x4002f7c2 PS : 0x00060330 A0 : 0x800268aa A1 : 0x3ffd26f0
A2 : 0x00000000 A3 : 0x00000000 A4 : 0x3ffcf8b8 A5 : 0x3ffcf8bc
A6 : 0x3ffcf8c0 A7 : 0x3ffcf8c4 A8 : 0x8002f7ad A9 : 0x3ffd26d0
A10 : 0x3cdb3940 A11 : 0x00000007 A12 : 0x00060320 A13 : 0x00000021
A14 : 0x00000074 A15 : 0x00000000 SAR : 0x0000001d EXCCAUSE: 0x00000006
EXCVADDR: 0x00000000 LBEG : 0x4000c46c LEND : 0x4000c477 LCOUNT : 0x00000000
ELF file SHA256: 0000000000000000
Backtrace: 0x4002f7c2:0x3ffd26f0 0x400268a7:0x3ffd2710 0x401ad0be:0x3ffd2750 0x4008869a:0x3ffd2770 0x40019d11:0x3ffd27a0 0x40055b4d:0x3ffd27c0 0x401a8a93:0x3ffd27e0 0x401a90a1:0x3ffd2800 0x40090f4a:0x3ffd2830
Rebooting...
Now for the real head scratcher: I went into our repo, and installed a variety of old firmware binaries on the ESP32. Our firmware from before June of 2021 works with the updated phone! So... I pull the source for that working firmware, build it, and am still getting the same crash behavior. This means it is not a source issue, but something that has changed in the underlying libraries or Arduino core. So I have now tried building our old firmware with every version of Arduino and the ESP32 libraries from that era, and still no luck.
What else could have changed that I'm missing? It has to be something on the system / compiler / library level, but I'm stumped as to what it could be.
Related
I'm running CouchDB with Yocto Dizzy on a LogicPD Torpedo with a 1GHz processor. I have multiple Android devices connected, making changes, and syncing with this database through some Java and Nodejs code. For the most part, it looks like the database is replicating properly across all devices.
However, I do have a frequent issue where a device will fall out of sync and the Android app on that device will have to be restarted. By "fall out of sync" I mean that changes are being made on one device, synced to the database, and not showing up on another device. I'm trying to troubleshoot this problem and I haven't been able to find any errors on the Android side. The errors I'm seeing in the CouchDB log are:
[Fri, 25 Sep 2015 14:47:59 GMT] [error] [<0.222.0>] ** Generic server <0.222.0> terminating
** Last message in was {'EXIT',<0.217.0>,killed}
** When Server state == {state,"http://X.XXX.X.X:XXXX/task/",20,[],
[<0.338.0>],
{[],[]}}
** Reason for termination ==
** killed
[Fri, 25 Sep 2015 14:47:59 GMT] [error] [<0.222.0>] {error_report,<0.31.0>,
{<0.222.0>,crash_report,
[[{initial_call,
{couch_replicator_httpc_pool,init,['Argument__1']}},
{pid,<0.222.0>},
{registered_name,[]},
{error_info,
{exit,killed,
[{gen_server,terminate,7,
[{file,"gen_server.erl"},{line,804}]},
{proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,237}]}]}},
{ancestors,
[<0.217.0>,couch_replicator_job_sup,
couch_primary_services,couch_server_sup,<0.32.0>]},
{messages,[]},
{links,[<0.338.0>]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,610},
{stack_size,27},
{reductions,390}],
[]]}}
[Fri, 25 Sep 2015 14:48:06 GMT] [error] [<0.130.0>] Error in replication `b16486bad369b219600dbd5bf0478e81+continuous+create_target` (triggered by document `9be140c9aa6334820aed80fa910275e4`): timeout
Restarting replication in 5 seconds.
[Fri, 25 Sep 2015 14:48:06 GMT] [error] [<0.88.0>] {error_report,<0.31.0>,
{<0.88.0>,supervisor_report,
[{supervisor,{local,couch_replicator_job_sup}},
{errorContext,shutdown_error},
{reason,killed},
{offender,
[{pid,<0.157.0>},
{name,
"98e4832e6f31a0962493d26092b5fe4e+continuous+create_target"},
{mfargs,{gen_server,start_link,undefined}},
{restart_type,temporary},
{shutdown,250},
{child_type,worker}]}]}}
When running the same programs and database on CentOS with an i7, it all works perfectly. I've tried mucking with tcp/ip kernel settings, as well as CouchDBs settings (local.ini, specifically os_process and timeout options).
Does anyone have any experience in this area? Any help would be greatly appreciated!
Iam trying to port Android Lollipop on arndale board and I am facing following issue regarding ART crash (AndroidRunTime).
> I/art ( 2264): RelocateImage: /system/bin/patchoat
> --input-image-location=/system/framework/boot.art --output-image-file=/data/dalvik-cach6 F/libc ( 2443): No [stack] line found in "/proc/self/task/2443/maps"! F/libc ( 2443): Fatal signal 6
> (SIGABRT), code -6 in tid 2443 (patchoat) W/art ( 2702): Could not
> create image space with image file >/system/framework/boot.art.
> Attempting to fall back to imageless running
STEPS FOLLOWED FOR PORTING
1.Download vexpress android L 32 bit code from below link.
http://releases.linaro.org/15.05/android
2.Download arndale android KK 32 bit source with 3.9 kernel from http://releases.linaro.org/14.08/android/arndale
3.Replace the Vexpress kernel source from code download in step 1 with arndale KK 3.9 Kernel source downloaded from step2.
4.Replace Vexpress HAL (device/linaro/vexpress) with Arndale HAL (device/linaro/arndale).
5.Solve minor complilation issues related to bionic and build environment.
After flashing the images and powering on the board I am stuck at android logo and kernel crashes
> >37.790000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 Tainted: G W (3.9.1 #8) [ 37.790000]
> CPU: 0 Tainted: G W (3.9.1 #8) PC is at
> __copy_to_user_std+0x4c/0x3a8 [ 37.790000] PC is at __copy_to_user_std+0x4c/0x3a8 LR is at 0x6c000000
> >[ 37.790000] LR is at 0x6c000000
and logcat gives
> >I/art ( 2264): RelocateImage: /system/bin/patchoat --input-image-location=/system/framework/boot.art --output-image-file=/data/dalvik-cach6 F/libc ( 2443): No [stack] line found in "/proc/self/task/2443/maps"! F/libc ( 2443): Fatal signal 6
> (SIGABRT), code -6 in tid 2443 (patchoat) W/art ( 2702): Could not
> create image space with image file >/system/framework/boot.art.
> Attempting to fall back to imageless running.
POINT OF EXACT FAILURE
1.ART calls Thread::InitStackHwm from art/runtime/thread.cc.
2.The above call triggers __pthread_attr_getstack_main_thread(stack_base, stack_size) in bionic/libc/bionic/pthread_attr.cpp which returns No [stack] line found in enter code here/proc/self/task/2443/maps! and ART crashes giving SIG_ABORT and it seems as if no stack is getting created for 2443 thread, but how to solve this?
It would be great if anyone can help me to solve this issue.
Thanks,
Devarsh
This is a side effect of using 3.9 kernel with linaro vexpress android platform which is expecting 3.10 kernel(whose support for arndale is not available).
As a workaround comment out the InitStackHwm() function in art/runtime/thread.cc.
I think if in 3.10 kernel support of arndale is needed we may not need this workaround and ART would work straightaway.
void Thread::Init(ThreadList* thread_list, JavaVMExt* java_vm) {
// This function does all the initialization that must be run by the native thread it applies to.
// (When we create a new thread from managed code, we allocate the Thread* in Thread::Create so
// we can handshake with the corresponding native thread when it's ready.) Check this native
// thread hasn't been through here already...
CHECK(Thread::Current() == nullptr);
SetUpAlternateSignalStack();
InitCpu();
InitTlsEntryPoints();
RemoveSuspendTrigger();
InitCardTable();
InitTid();
// Set pthread_self_ ahead of pthread_setspecific, that makes Thread::Current function, this
// avoids pthread_self_ ever being invalid when discovered from Thread::Current().
tlsPtr_.pthread_self = pthread_self();
CHECK(is_started_);
CHECK_PTHREAD_CALL(pthread_setspecific, (Thread::pthread_key_self_, this), "attach self");
DCHECK_EQ(Thread::Current(), this);
tls32_.thin_lock_thread_id = thread_list->AllocThreadId(this);
//InitStackHwm(); This is the workaround
tlsPtr_.jni_env = new JNIEnvExt(this, java_vm);
thread_list->Register(this);
}
So, I knew nothing about ARM instructions and have only just started trying to understand it. I've looked up a bit on ARM and some of the better links were these:
Converting very simple ARM instructions to binary/hex
http://simplemachines.it/doc/arm_inst.pdf
According to the first link, instructions have the following format and are 32-bits:
[cond][00][immediate][opcode][alerts condition codes?][Rn][Rd][Operand 2]
However, when I disassembled some .so files, I saw that most some of the instructions were 16 bits and had a different format.
Why the discrepancy? Is there a spec. for this?
An example would be how it encodes mov.
A simple mov r0 #255 is 20ff, only 16 bits as opposed to 32. Strange (to me).
As I understand it, you can't normally specify an entire 32-bit value in one instruction. I don't know the syntax for assemblers to compile.
What I've been doing is editing existing .so files using a hex editor.. And running them.
I tried to AND two values but just couldn't do it, something like:
mov r0 #63 ;0x003f
mov r1 #16896 ;0x4200
and r0, r0, r1, lsl #8 ;should be 0x423f at this point
mov r15, r14 ;method returns at this point, right?
Except, I didn't have an assembler and had to do it like this:
Find method that returns int in disassembled .so file
Over-write entries
Run and see output
So, this is what I got:
mov r0 0x003f - 1110 00 1 1101 0 0000 0000 0000 00111111 - e3a0 003f
mov r1 0x0042 - 1110 00 1 1101 0 0000 0001 0000 01000010 - e3a0 1042
and r0, r0, r1, lsl #8 - 1110 00 0 0000 0 0000 0000 00001000 0001 - e000 0081
mov r15, r14 - 1110 00 0 1101 0 0000 1111 0000 0000 1110 - e1a0f00e
So.. Yeah, I thought about instructions, encoded them using a table, used a calculator to convert it into hex, used a hex editor, transferred to my phone and ran the app..
And I just kept getting a zero when the method was called. Am I missing something here?
So..
Yeah.
Why does android's ARM seem to have 16 bit instructions mixed with 32 bit instructions and why isn't my little attempt working?
Do realize that when you say 'ARM instructions' that isn't just one instruction set but a multitude depending on the architecture and what extensions are supported. The document you linked to starts off by mentioning architecture v4 which if you check your favorite wiki for 'ARM architecture' - it would point out that v4 is a 'legacy' architecture.
Android itself started support on ARMv6 with most modern devices running ARMv7 or ARMv7a. While I don't know for sure I would think that the 16 bit instructions are Thumb2 and not the original Thumb extension which was intended to improve code density as ARM was designing for the embedded market of 10 to 20 years ago where a megabyte would be a lot of memory.
If you are learning, I would reference ARM's documentation available at their website:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0406b/index.html
and possibly look at the ARM instructions coming out of gcc:
http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
and get a cross-compiler for ARM setup so that you can take a higher level language like C and generate ARM binaries.
My Android application (using native library) print this warning on Android 4.4 :
linker mylib.so has text relocations. This is wasting memory and is a security risk. Please fix.
Have you got an idea of what it is and how to fix it ?
Thanks,
This would appear to be a result of two ndk-gcc bugs mentioned at https://code.google.com/p/android/issues/detail?id=23203
and stated there to have been fixed as of ndk-r8c.
It would appear that the check for libraries with the issue has been added only recently.
Note: please do not edit this post to hide the link URL. It is explicit because the destination is what makes it authoritative.
Further Note Changing NDK versions is only a fix when the warning is due to the code of your application. It will have no effect if the warning is instead on a system component such as libdvm - that can only be fixed by a system update.
You need to make the code in your library position independent...add -fpic or -fPIC to your LOCALC_FLAGS in your Android.mk and you also need to ensure that you're not linking against any static or shared libraries that contain text relocations themselves. If they do and you can re-compile them, use one of the flags mentioned above.
In short, you need to compile your library with one of the -fpic or -fPIC flags, where PIC is an abbreviation for Position Independent Code.
The longer answer is that your yourlib.so has been compiled in a manner that does not conform to the Google Android standard for an ELF file, where this Dynamic Array Tag entry is unexpected. In the best case the library will still run, but it is still an error and future AOS version will probably not allow it to run.
DT_TEXTREL 0x16 (22)
To check whats in you library use something along the line of:
# readelf --wide -S yourlib.so
There are 37 section headers, starting at offset 0x40:
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 0000000000000000 002400 068f80 00 AX 0 0 16
[ 2] .rodata PROGBITS 0000000000000000 06b380 05ad00 00 WA 0 0 32
...
[16] .rela.text RELA 0000000000000000 26b8e8 023040 18 14 1 8
...
[36] .rela.debug_frame RELA 0000000000000000 25a608 0112e0 18 14 27 8
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
Please see my extensive answer on the topic, for more DT entry details. For details how to write proper dynamic libraries this is a must-read.
I got the same error with my application.
The application was using a native daemon that used a native library which was not implementing all the functions in its header file. When I added the required implementations to the native library everything just worked.
I don't know if you have the exact same issue but it just probably means the your native side has some mismatch.
I've a Samsung Galaxy SIII with Android 4.1.2 "rooted". I need to measure the CPU usage for some multithreaded applications I've written in C/C++, however I need this information in a per core basis.
I know (due wikipedia, ...) that the Galaxy has a SoC with 4 ARM Cortex A9 however when I do a cat /proc/cpuinfo it doesn't show any information regarding the number of available cores (as usual in any Linux), is this correct behavior?
I've read somewhere that I can use cat /proc/stat to see the per core load average however, in my device, the content of such "file" only shows information for the "core0", again, is this correct or do I need to do something to enable all cores?
I also tried with top and ps without success.
EDITED:
----------------- cat /proc/cpuinfo
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 1592.52
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc09
CPU revision : 0
Chip revision : 0011
Hardware : SMDK4x12
Revision : 000c
Serial : 11e16f694df1267e
----------------- cat /proc/stat
cpu 89515 1686 23283 464122 3835 2 376 0 0 0
cpu0 74214 457 16736 221609 1111 1 347 0 0 0
intr 1860068 0 0 0 0 0 0 0 0 0 0 .... (removed: a serie of numbers)
ctxt 3138146
btime 1371578546
processes 15904
procs_running 1
procs_blocked 0
softirq 1154788 12 403499 864 4501 12 12 444746 67202 576 233364
You can get information about the number of cores by examining the hotplug devices, /sys/devices/system/cpu/present and /sys/devices/system/cpu/possible. See also the hotplug docs.
I'm not sure this helps you much as far as getting CPU usage. You can get a crude sense for how much user and system time a thread has used from adb shell ps -x -t, e.g.:
USER PID PPID VSIZE RSS WCHAN PC NAME
system 19598 19574 955672 57324 ffffffff 4012d9b8 S system_server (u:2186, s:1521)
system 19602 19598 955672 57324 c007f840 4012db84 S GC (u:79, s:6)
This says that system_server's main thread has used 2186 ticks of user time, while the GC thread has used 79 ticks.
If you can instrument your application, you can use the POSIX clock_gettime() call with CLOCK_THREAD_CPUTIME_ID to measure the amount of CPU time used by a given thread. (The Dalvik VM uses this when generating results for traceview.)
This is all per-thread, however. Getting per-core usage information is much harder, especially on Android:
The hotplug mechanism can add or remove cores during your test.
The kernel can adjust the CPU frequency of each core individually, so doing X amount of work may take different amounts of time on different cores.
Threads can migrate between cores (by default there is no core affinity).
It should include the different cores (showing Nexus 7):
$ adb shell cat /proc/cpuinfo
Processor : ARMv7 Processor rev 9 (v7l)
processor : 0
BogoMIPS : 1993.93
processor : 1
BogoMIPS : 1993.93
processor : 2
BogoMIPS : 1993.93
processor : 3
BogoMIPS : 1993.93
and stat:
$ adb shell cat /proc/stat
cpu 1623573 112801 907626 32541158 125987 68 5952 0 0 0
cpu0 804181 45734 569092 7373416 43990 49 4990 0 0 0
cpu1 332438 26759 142892 8311267 31256 9 574 0 0 0
cpu2 332889 25551 130711 8319093 30900 7 218 0 0 0
cpu3 154065 14757 64931 8537382 19841 3 170 0 0 0
You can check if a core is Online/offline by reading the file
/sys/devices/system/cpu/CPUx/online (x is the number of the core and in Samsung S3: 0,1,2,3)
if it is "0" , the core is Offline and if it is "1" the core is online. Now, you can use /proc/stat to calculate CPU Usage but for Samsung S3 it will only show the cores which are active at the time you read /proc/stat. Now, to calculate CPU Usage for all the cores, you have to force all the cores online. You can use System Tuner App available at Play store: https://play.google.com/store/apps/details?id=ccc71.pmw&hl=en for forcing all the cores online. Install the app and then put the cores online by ( CPU -> Boot settings -> Force all CPUs online -> On boot Completed ), now you can reboot your device and all the cores are online. Now read /proc/stat and calculate CPU Usage for all the cores. If you need more explanation about /proc/stat http://www.linuxhowtos.org/System/procstat.htm
can help.
I noticed that load gets distributed among all the active cores (must be some system processes), I was running Skype over Wifi and without forcing all the cores online it was using 2 cores: core 0 and core 1 at 30% and 25% respectively. I measured the CPU Usage again for the same use case(Skype over wifi) after forcing all the cores online and I noticed that load was distributed among all active cores ( Core1: 26% , Core 2: 9%, Core 3: 11%, Core 4: 10% ).