Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an application that runs on an embedded Linux device that I am expanding with new features. The new features require GLib so, I am dynamically linking the required libraries to the application.

When I do this and run the application on the device, I get a segmentation fault. This occurs when I dynamically link the new libraries. GDB's backtrace shows that the fault occurs in another custom dynamically linked library. Unfortunately I only get a partial trace with the following message:

Backtrace stopped: frame did not save the PC

Note that I am only linking another shared library and not adding any new code. If I linked the custom library statically the crash goes away. I suspect a memory corruption is happening somewhere else and the conditions (i.e. memory mapping) are just right when the custom library is dynamically linked so that the segmentation occurs.

Anyone know of any good tools and techniques I can use to debug further?

share|improve this question
Are you compiling the custom libraries with debug symbols enabled? – Faheem Mitha Aug 15 '12 at 16:17
@Faheem: Yes, everything is built with debug symbols – waffleman Aug 15 '12 at 17:52
could you post the whole backtrace? – djf Aug 15 '12 at 22:35
In addition to Faheem's question. Is there a limit on the size of the coredump? – Karlson Aug 16 '12 at 12:40
@Karlson: Unlimited. Also, optimizations are disabled. The back trace itself is not very useful. It only contains three stack frames from a custom library and not variables are available. – waffleman Aug 16 '12 at 13:02

There has been a discussion on similar subject on Gmane and Gentoo forums, so the answer may be found there.

In addition I would suggest starting with looking that your program at run time will load the right libraries so try ldd the dynamically linked file to see that you are actually running against right versions and then run the program through valgrind because it's entirely possible that you are addressing memory you shouldn't and valgrind will be able to show that to you.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.