Hi all,

I am currently working with some c++ code on an ARM processor. The issue i am having is that when my application hits a segfault i am unable to get any information as to what caused it.

My dev machine is ubuntu 10.04 LTS and i am using eclipse as my IDE (just for how it looks, the compliation is a makefile using autoconf). Im using the GCC ARM cross compiler from openembedded and the cross compiled GDB also from openembedded. Output of compiler version below.

arm-angstrom-linux-gnueabi-g++ -v
Using built-in specs.
Target: arm-angstrom-linux-gnueabi
Configured with: /home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/gcc-cross-4.3.3-r23.2/gcc-4.3.3/configure --build=i686-linux --host=i686-linux --target=arm-angstrom-linux-gnueabi --prefix=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a --exec_prefix=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a --bindir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/bin --sbindir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/bin --libexecdir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/libexec --datadir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/share --sysconfdir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/etc --sharedstatedir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/com --localstatedir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/var --libdir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/lib --includedir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/include --oldincludedir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/include --infodir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/share/info --mandir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/share/man --enable-largefile --disable-nls --enable-ipv6 --with-gnu-ld --enable-shared --enable-languages=c,c++,objc,fortran --enable-threads=posix --disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-angstrom-linux-gnueabi- --enable-target-optspace --enable-cheaders=c_std --enable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap --with-sysroot=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/armv7a-angstrom-linux-gnueabi --with-build-sysroot=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/armv7a-angstrom-linux-gnueabi --with-build-time-tools=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/bin --enable-cheaders=c_std --disable-libunwind-exceptions --with-mpfr=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr --program-prefix=arm-angstrom-linux-gnueabi- --enable-__cxa_atexit
Thread model: posix
gcc version 4.3.3 (GCC)

Im not sure exactly how much of that may be relevant to this discussion but ill include it incase.

So what i found doing some google'ing is that lots of people just saying run back trace when GDB halts the program, but i do not get a trace. I dont know if this is because i am cross compiling or what the issue is. Here is a backtrace i got earlier.

Stopped due to shared library event
[New Thread 17266]
[Switching to Thread 17266]

bt
#0  0x96969694 in ?? ()
#1  0x96969696 in ?? ()
#2  0x96969696 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

If anyone has seen this before and knows how i can get the location of the seg fault without having to write custom event handlers i would really appreciate it( even to the last function call in my code would be accurate enough ).

Many thanks

You can trash your stack to the point that the bt information is lost. If you can build your programme to run on your Linux machine, run your programme under valgrind (be sure to have built a version with debug symbols) and if you're stomping all over your own memory, it'll tell you.

Thanks for the response, i have valgrind on my arm system, would i be right to expect that i can use it on the arm platform to get the same effect?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.