I am using DDD (and also kdbg) with GDB. My programming is segfaulting in a function. When I try to debug, I can get to the function that calls that function, but in the stack window the debugger shows the function that actually has the problem as being in a library without debug symbols. It will not show the code for it. The rest of my functions in the stack show up fine, including functions in the same library that won't show up for the problem function.

One thing to note is that there is a small change the library could be dynamically loaded at that point, rather than just dynamically linked. But I would think dl_open()ed libraries would work properly in the debugger.

Is there any likely cause of this?

This is in C/C++.

What you see is expected debugger behavior.

What you passed to the library is highly suspect. Unless you wrote it as well.
You can see this with non-null terminated strings going into string.h library routines like strcmp() or strchr().

What do you mean by this, and why would it make the debugger do this?

I'd like to add that this is the only C++ function in the stack, if that could be an issue.

You didn't mention C++.

The 'suspect' thing is: let's assume you are calling a well-tested library module that is stack dumping. The most common cause for a stack dump in this case is a bad pointer. If you are calling a brand-new library that you wrote, then you can compile the library so that symbols are retained. And since the library is untested, it could likely be a problem in the library code as well.

C++ links code to some different base run-time libraries as well as stdc libraries.

The library is not brand new, and has been extensively tested, but not on linux. There could be a bad pointer.

As I understand it, you're saying some problems prevent the debugger from showing code for a function?

How can this be remedied?

Recompile the said library with debugging symbols.