Develop Reference

Every runtime error reported as SIGSEGV error in android studio

I have linked some c++ codes to android studio project and it works with no problem, but every time I encounter with a runtime error in java code, android studio won't tell me the problem precisely and reports only this error in debugger:
Signal = SIGSEGV (signal SIGSEGV: invalid address (fault address: 0xc))
What is the problem?

This primarily occurs due to one of the 2 reasons :
1) Invalid memory reference.
2) Eating up too much memory.
Now, debugging this issue can be a bit intimidating.
So start finding out points where your code may be doing INVALID MEMORY ACCESS causing SIGSEGV error or points where your code is starting too many threads.
And You have to find out if this issue is regularly occuring or 1 in 5(or so) times.
Because I encountered the problem in one project and that occured 1 in 5-6 times.

Where to find source code of Android DDMS tool -- Alocation Tracker?

can anybody tell me where to find the source code of Allocation Tracker, the memory trace tool in Android DDMS?(http://grepcode.com/file/repo1.maven.org/maven2/com.android.ddmlib/ddmlib/r16/com/android/ddmlib/Client.java#Client.requestAllocationDetails%28%29)
Or, are there any other ways to analysis the memory allocation and find out how much memory each class uses within an Android app/process?

Android crashlytics app crashes on launch due to TypeNotPresentException

Crashlytics compile('com.crashlytics.sdk.android:crashlytics:2.4.0#aar') is integrated with the app and is being tested on nexus 7 4.4.4,
The crash is seen from application onCreate method and following stacktrace is obtained. No other similar error/explaination could be found on stackoverflow.
Any suggestions are welcome.
Caused by: java.lang.TypeNotPresentException: Type com/crashlytics/android/core/internal/CrashEventDataProvider not present
at java.lang.Class.getDeclaredAnnotation(Native Method)
at java.lang.Class.getAnnotation(Class.java:290)
at io.fabric.sdk.android.Kit.containsAnnotatedDependency(Kit.java:158)
at io.fabric.sdk.android.Kit.compareTo(Kit.java:140)
at io.fabric.sdk.android.Kit.compareTo(Kit.java:33)
at java.util.ComparableTimSort.countRunAndMakeAscending(ComparableTimSort.java:291)
at java.util.ComparableTimSort.sort(ComparableTimSort.java:153)
at java.util.ComparableTimSort.sort(ComparableTimSort.java:142)
at java.util.Arrays.sort(Arrays.java:1970)
at java.util.Collections.sort(Collections.java:1864)
at io.fabric.sdk.android.Fabric.initializeKits(Fabric.java:401)
at io.fabric.sdk.android.Fabric.init(Fabric.java:375)
at io.fabric.sdk.android.Fabric.setFabric(Fabric.java:332)
at io.fabric.sdk.android.Fabric.with(Fabric.java:303)
at com.xxxx.MainApplication.onCreate(MainApplication.java:19)

Apparently android limiatation of 65K methods is the problem on pre-lollipop devices, the problem is not due to crashalytics library per-se but in general one might run into this problem due to limitation of 65K methods at dalvik level.
Thanks to http://frogermcs.github.io/MultiDex-solution-for-64k-limit-in-Dalvik/ I was able to get the no. of methods in my .apk file.

Multidex with Android 2.3 (API 9)

can anyone tell me if multi dex is supported in android 2.3?
I've searched around but i can't find information for this.
My project have the same configuration like this one: https://github.com/mustafa01ali/MultiDexTest
The project builds without problem, but the final apk can't be installed in devices with 2.3 or lower.
On installation I get the error
Failure [INSTALL_FAILED_DEXOPT]
in Android Studio and this appears in logcat:
E/dalvikvm﹕ LinearAlloc exceeded capacity (5242880), last=1384
W/installd﹕ DexInv: --- END '/data/app/xxx.apk' --- status=0x000b, process failed
E/installd﹕ dexopt failed on '/data/dalvik-cache/data#app#xxx.apk#classes.dex' res = 11

You're hitting a different size limitation (LinearAlloc), which according to this bug is not solved by multi-dex:
https://code.google.com/p/android/issues/detail?id=78035
From comment #7 in that bug:
There is already an option in dx allowing to force generation of
smaller dex files:
--set-max-idx-number= Unfortunately changing the default is not a solution since the linearAlloc limit can be reached at very
different levels depending on the classes hierarchy and other
criteria.
In addition for most applications, moving to multidex will only help
to workaround the linearalloc limit for the installation. But the
application will still crash against the same limit at execution. The
only working use case where I know multidex can help with linearalloc
is when the apk does not contains one application but distinct pieces
running in separate process.
It's not clear that there's anything you can do to work around this limit, at least in the long term; you may need to simplify your app. There's another StackOverflow question here with some information and some workarounds that may get you up and running, at least for a while:
How to avoid LinearAlloc Exceeded Capacity error android

Loadable Kernel Module: Unknown symbol malloc_sizes (err 0)

I have developed a Loadable Kernel Module (LKM) for android.
I use kzalloc:
device = kzalloc(ndevices * sizeof (*device), GFP_KERNEL);
and it worked for a while, but after an update of my android (since 4.1 it's no more working), I got following error on insmod:
insmod module.ko
insmod: init_module 'module.ko' failed (No such file or directory)
DMESG says:
Unknown symbol malloc_sizes (err 0)
This has something to do with inux/slab.h, that's what I know.
I googled for days over days and I'm very frustrated not finding the solution to fix this problem and get the LKM working again.
Can maybe anyone help me out?
CONCLUSION:
The accepted answer is correct: Try to remove the slab.h and define the missing methods as "extern". Or in your kernel-source, use "make menuconfig" and change SLAB to SLUB (see first comment in answer for more details).
The remaining problems are handled in a new, more specific topic:
Interchangeability of compiled LKMs

So you need to tell us the kernel versions. But looking up linux kernel versions and memory allocators, it looks like the default mainline kernel switched from SLAB to SLUB.
By default, Linux kernel used a SLAB Allocation system until version
2.6.23, when SLUB allocation became the default.
Unless you're writing a module or something that depends on SLAB (which is very highly unlikely), then you probably don't want to be including linux/slab.h headers.