How to debug heap corruption on armv5_问答_开发者

开发者 https://www.devze.com 2023-04-05 19:22 出处：网络

I am on linux on an embedded dev开发者_如何学编程ice. My architecture is armv5. My fairly large (~30kloc) has some kind of heap corruption that happens over time.

I am on linux on an embedded dev开发者_如何学编程ice. My architecture is armv5.

My fairly large (~30kloc) has some kind of heap corruption that happens over time.

I cannot run valgrind since my arch is not supported. I can only run a limited gdb since my app uses thread and the corruption most probably happens in one of the thread.

I get

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

libthread_db and libpthread come from my gnueabi toolchain.

I was wondering what was the best course of actions now. Should I keep trying to get libthread_db to work with gdb? Or is there some other tool like valgrind that I could use?

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

This error means that GDB attempted to dlopen every libthread_db.so.1 from libthread-db-search-path (use show libthread-db-search-path to see what that is), and all versions of libthread_db.so.1 failed to work with libpthread that you have on the target (your embedded device).

Most likely your libthread-db-search-path is simply incorrect.

Another possibility is that your toolchain shipped (say) i686-linux version of libthread_db.so.1, but you are using GDB built for x86_64-linux. 64-bit GDB (obviously) can't dlopen 32-bit libthread_db.

Even if you manage to set up multi-threaded debugging properly (which you should try in any case), it is quite unlikely that that will help you find heap corruption problem: usually by the time you get a crash due to heap corruption, all traces of code that actually caused it have disappeared.

If you are using glibc on target, MALLOC_CHECK_=2 might help. Documentation here.

If you are using some other libc, it may have similar malloc debugging facilities. Or you could try one of the many debug mallocs available.

The answers to this question have very good guidelines. I would give electricfence a run. This paper is also very informative(even if it talks\uses valgrind).