Obsolete
Status Update
Comments
di...@android.com <di...@android.com> #2
Thank you for your feedback. We assure you that we are doing our best to address the issue reported, however our product team has shifted work priority that doesn't include this issue. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with latest bug report here https://goo.gl/TbMiIO .
st...@gmail.com <st...@gmail.com> #3
Is there a workaround for this? Currently, we've downgraded to NDK 8c to work around this, but that solution is less than ideal.
m....@gmail.com <m....@gmail.com> #4
We also have had to stay with a NDK v8 to deal with this problem. Any help Google?
de...@antonsmirnov.name <de...@antonsmirnov.name> #5
Any fix/workaround? Probably working with another gcc/ndk version?
de...@antonsmirnov.name <de...@antonsmirnov.name> #7
using ndk10b with gcc-4.8
an...@gmail.com <an...@gmail.com> #8
same.. using ndk10b with gcc-4.8. Please notify if fixed
ha...@gmail.com <ha...@gmail.com> #9
I worked around with this problem.
Only in case of you are not using 64bit atomic operation which GCC provides, just drop "linux-atomic-64bit.o" from libgcc.a and link it.
(You had better save in different name with the original.)
Other object files don't have "kernel helper version check routine", it works well.
Otherwise, you can solve by implementing equivalent functions by yourself which doesn't depend on kernel, and swap the object file.
Good luck! ;-)
Only in case of you are not using 64bit atomic operation which GCC provides, just drop "linux-atomic-64bit.o" from libgcc.a and link it.
(You had better save in different name with the original.)
Other object files don't have "kernel helper version check routine", it works well.
Otherwise, you can solve by implementing equivalent functions by yourself which doesn't depend on kernel, and swap the object file.
Good luck! ;-)
en...@google.com <en...@google.com>
at...@gmail.com <at...@gmail.com> #10
Can anyone explain why this issue only appears on newer ndks (10d) but not older ones (8b), even though I'm using the same compiler version (4.6)?
xc...@gmail.com <xc...@gmail.com> #11
[Comment deleted]
xc...@gmail.com <xc...@gmail.com> #12
same problem ndk10e gcc 4.9 arm
ks...@google.com <ks...@google.com> #13
Closing this since gcc is deprecated and it was an issue with older devices 2 years ago.
Description
this is the backtrace:
08-02 18:36:08.200: I/sec_anm_ahi_output(1535): setParameters(stop_output_streamtype=1)
08-02 18:36:08.360: I/DEBUG(18804): #00 pc 000162a0 /system/lib/libc.so (__libc_android_abort)
08-02 18:36:08.360: I/DEBUG(18804): #01 pc 00418334 /data/data/
08-02 18:36:08.360: I/DEBUG(18804): libc base address: afd00000
After searching a little bit, it seems the problem is in 64-bit atomic as it seems my compiled code it's not using dmb instructions instead it's calling kernelhelper:
The workaround it's to compile for armv7-a, but I'm already doing this with the same results. These are the flags I'm using:
CPU=armv7-a
OPTIMIZE_CFLAGS="-march=$CPU -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb -D__thumb__"
EXTRA_LDFLAGS="-Wl,--fix-cortex-a8 -march=armv7-a"
PREFIX=./android/$CPU
EXTRA_CONFIGURE=""
I have also tried with these, but with same results:
CPU=armv7-a
OPTIMIZE_CFLAGS="-march=$CPU -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb -D__thumb__"
EXTRA_LDFLAGS="-Wl,--fix-cortex-a8 -march=armv7-a"
PREFIX=./android/$CPU
EXTRA_CONFIGURE="--disable-armv5te --disable-armv6 --disable-armv6t2"
I have tested on different devices and these are the results:
Nexus 4 - No Crash
Nexus 7 - No crash
Galaxy sII - Crash
Galaxy Ace 2 - Crash
I would appreciate any help.
Thanks.