Android 无效的堆地址和致命信号 11
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10662446/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Invalid heap address and fatal signal 11
提问by adneal
Every so often my app will crash and my log will read:
每隔一段时间我的应用程序就会崩溃，我的日志会显示：
@@@ ABORTING: INVALID HEAP ADDRESS IN dlfree
Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)
Sometimes code=2, but always Fatal signal 11and invalid heap address.
有时code=2，但总是Fatal signal 11和invalid heap address。
I've tried researching what this means and how to fix it. This thread has been the most helpful; however, I'm still without a solution.
我已经尝试研究这意味着什么以及如何解决它。这个线程是最有帮助的；但是，我仍然没有解决方案。
The error occurs when I run a couple of AsyncTasksto download several images.
当我运行几个AsyncTasks以下载多个图像时发生错误。
This is my main AsyncTask
这是我的主要 AsyncTask
public class FetchArtistImages extends AsyncTask<Void, Integer, String[]> implements Constants {
private final WeakReference<Context> contextReference;
public FetchArtistImages(Context context) {
contextReference = new WeakReference<Context>(context);
}
@Override
protected String[] doInBackground(Void... params) {
String[] projection = new String[] {
Audio.Artists._ID, Audio.Artists.ARTIST
};
String sortOrder = Audio.Artists.DEFAULT_SORT_ORDER;
Uri uri = Audio.Artists.EXTERNAL_CONTENT_URI;
Cursor c = contextReference.get().getContentResolver()
.query(uri, projection, null, null, sortOrder);
ArrayList<String> artistIds = new ArrayList<String>();
if (c != null) {
int count = c.getCount();
if (count > 0) {
final int ARTIST_IDX = c.getColumnIndex(Audio.Artists.ARTIST);
for (int i = 0; i < count; i++) {
c.moveToPosition(i);
artistIds.add(c.getString(ARTIST_IDX));
}
}
c.close();
c = null;
}
return artistIds.toArray(new String[artistIds.size()]);
}
@Override
protected void onPostExecute(String[] result) {
for (int i = 0; i < result.length; i++) {
new LastfmGetArtistImages(contextReference.get()).executeOnExecutor(
AsyncTask.THREAD_POOL_EXECUTOR, result[i]);
}
super.onPostExecute(result);
}
Even though I've tried researching what's up with this, I still find myself lost when it comes to fixing it. If anyone has some insight, I'd definitely appreciate seeing it. The error isn't thrown every time I executemy AsyncTasks, but I can't find much of a pattern to help isolate why this is occurring. There are a couple of other threads on SO about fatal signal 11, but they don't provide much help in my case.
尽管我已经尝试研究这是怎么回事，但在修复它时我仍然发现自己迷失了方向。如果有人有一些见解，我肯定会很高兴看到它。每次我execute我的时候都不会抛出错误AsyncTasks，但我找不到太多模式来帮助确定发生这种情况的原因。SO about 上还有其他几个线程fatal signal 11，但在我的情况下，它们没有提供太多帮助。
回答by Ivan
I just ran into the same issue and had it at a re-producable state. This is the error I was getting:
我刚刚遇到了同样的问题，并使其处于可重现的状态。这是我得到的错误：
08-04 17:37:05.491: A/libc(4233): @@@ ABORTING: INVALID HEAP ADDRESS IN dlfree 08-04 17:37:05.491: A/libc(4233): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)
08-04 17:37:05.491：A/libc(4233)：@@@ ABORTING：dlfree 中的无效堆地址 08-04 17:37:05.491：A/libc(4233)：致命信号 11 (SIGSEGxdeadV) 在 08-04 （代码=1）
What it boiled down to is a function call being made from two different threads at the same time.
它归结为同时从两个不同的线程进行的函数调用。
More specifically, this function was BluetoothSocket's close() method.
更具体地说，这个函数是BluetoothSocket 的close() 方法。
I checked the source code at this website, and the call is not synchronized (not sure if this changed since it is from Android 2.1).
我检查了这个网站上的源代码，调用没有同步（不确定这是否改变了，因为它来自 Android 2.1）。
At any rate, do you maybe have a similar scenario where a function call is made from multiple threads? Can't say for sure from the source code you're showing.
无论如何，您是否有类似的场景，即从多个线程进行函数调用？从您显示的源代码中无法确定。
Also have you tried not using THREAD_POOL_EXECUTOR? According to the android dev guide:
你也试过不使用 THREAD_POOL_EXECUTOR 吗？根据android开发指南：
When first introduced, AsyncTasks were executed serially on a single background thread. Starting with DONUT, this was changed to a pool of threads allowing multiple tasks to operate in parallel. Starting with HONEYCOMB, tasks are executed on a single thread to avoid common application errors caused by parallel execution.
首次引入时，AsyncTasks 在单个后台线程上串行执行。从 DONUT 开始，这已更改为允许多个任务并行操作的线程池。从 HONEYCOMB 开始，任务在单个线程上执行，以避免并行执行导致的常见应用程序错误。
回答by PolyMesh
I had this same error yesterday. It always happened but not always consistently. What caused it for me has so far not been mentioned.
我昨天有同样的错误。它总是发生，但并不总是一致的。到目前为止还没有提到是什么导致了我。
I thought I might have a similar issue because I too was dealing with threads, however I removed all my threading and the problem was still occurring. Finally after a bunch of print statements I was able to track it down to a class I had instanced which had a pointer as a private member, but I forgot to initialize the pointer.
我想我可能有类似的问题，因为我也在处理线程，但是我删除了所有线程并且问题仍然存在。最后，在一堆打印语句之后，我能够将它跟踪到我实例化的一个类，该类有一个指针作为私有成员，但我忘记了初始化该指针。
Later when that class destructed it was trying to delete the pointer, however because the pointer was not initialized to NULL, it may or may not have some garbage value, so sometimes it would not cause a crash and other times it would. It is probably because when the garbage value was a memory location that doesn't belong to me or when it does and I delete something important, it causes the crash/error.
后来当那个类析构它试图删除指针时，但是因为指针没有初始化为 NULL，它可能有也可能没有一些垃圾值，所以有时它不会导致崩溃，有时它会。这可能是因为当垃圾值是一个不属于我的内存位置时，或者当它确实存在并且我删除了一些重要的东西时，它会导致崩溃/错误。
Here's a stripped down example of the problem I encountered:
这是我遇到的问题的精简示例：
class BadFoo
{
public:
BadFoo() {} // BAD! We didn't initialize the pointer
~BadFoo() {
if (myPtr) {
delete myPtr;
}
}
// OTHER MEMBER FUNCTIONS HERE
private:
int* myPtr;
}
class GoodFoo
{
public:
GoodFoo() : myPtr(NULL) {} // GOOD! Can't be garbage value now
~GoodFoo() {
if (myPtr) {
delete myPtr;
}
}
// OTHER MEMBER FUNCTIONS HERE
private:
int* myPtr;
}
Interesting to note, this crash did not occur on my Transformer Prime, but did on my Nexus4. Just goes to show we should test on multiple devices! So far the Nexus wins on helping me track down bugs as it seems to be a lot pickier.
有趣的是，这次崩溃没有发生在我的 Transformer Prime 上，而是发生在我的 Nexus4 上。只是表明我们应该在多个设备上进行测试！到目前为止，Nexus 在帮助我追踪错误方面获胜，因为它似乎更加挑剔。
