1

I am on linux on an embedded device. 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?

Eric
  • 19,525
  • 19
  • 84
  • 147
  • 1
    Can a) port the code to your desktop OS and valgrind it there, or b) replace global `new` and track allocations? – Kerrek SB Sep 19 '11 at 21:53
  • How can I replace global new? – Eric Sep 19 '11 at 21:56
  • http://www.informit.com/articles/article.aspx?p=30642&seqNum=3 – celavek Sep 19 '11 at 22:04
  • @Eric: [Here's a start](http://stackoverflow.com/questions/4421706/operator-overloading/4421791#4421791). [Here's more.](http://stackoverflow.com/questions/7194127/how-should-i-write-iso-c-standard-conformant-custom-new-and-delete-operators/) – Kerrek SB Sep 19 '11 at 22:06

2 Answers2

3

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.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • I am aware of the libthread-db-search-path config, but it does not solve my problem unfortunately. Both my toolchain and gdb run on my device, I've cross compiled gdb with the said toolchain – Eric Sep 20 '11 at 19:19
  • Also I am using C++ so I don't have any mallocs, only news. Is this still going to work? – Eric Sep 20 '11 at 19:19
  • My bet with gdb was to check for the memory location of a particular variable getting overwritten then setting a memory watch on that location. Might or might not work... – Eric Sep 20 '11 at 19:21
1

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).

Community
  • 1
  • 1
celavek
  • 5,575
  • 6
  • 41
  • 69