2

I have a C++ code built for ARM target using linaro toolchain built specifically from source for the ARM hardware target (with softfp, mtune=cortex-a9 etc...) At times, the code crashes with below trace. I had attached gdb to the running process Apparently it seems to crash few calls after a new operator from libstdc++.so.6 is invoked.

We at moment don't have exception handling code, so If new was failing and throwing exception i presumed it would have aborted/terminated with message like:

Program received signal SIGABRT, Aborted.

but instead it crashes with SIGSEGV.

Why is that so? What could be going wrong ?

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x45c6b460 (LWP 1182)]
0x402fad12 in malloc_consolidate () from /lib/libc.so.6
#0  0x402fad12 in malloc_consolidate () from /lib/libc.so.6
#1  0x402fc498 in _int_malloc () from /lib/libc.so.6
#2  0x402fe414 in malloc () from /lib/libc.so.6
#3  0x401f54d6 in operator new(unsigned int) () from /lib/libstdc++.so.6
#4  0x400f30d4 in MyMsg::operator=(MyPkt*) () from /usr/lib/libmy-ARMV7AL.so
#5  0x400f322c in MyMsg::reply() () from /usr/lib/libmy-ARMV7AL.so
#6  0x0005a6a0 in MyManager::SendMessage (this=0x7188c8)
    at MyManager.cpp:12973
#7  0x0004389c in My::Response (this=0x7188c8)
    MyManager.cpp:5972
goldenmean
  • 18,376
  • 54
  • 154
  • 211
  • Check [this](http://stackoverflow.com/questions/3100193/segfaults-in-malloc-and-malloc-consolidate) and [this](http://stackoverflow.com/questions/6725164/segmentation-fault-in-malloc-consolidate-malloc-c-that-valgrind-doesnt-detect) out. – jrok Oct 16 '13 at 09:43
  • You're destroying the heap somewhere. There could be something with `MyManager::SendMessage` or `MyMsg::reply` or `MyMsg::operator=`. Or it could be something else, it's hard to tell from a stack trace. – molbdnilo Oct 16 '13 at 09:45
  • @jrok - thanks will read those links. – goldenmean Oct 16 '13 at 09:53
  • Posting function definition of MyManager::SendMessage() and My::Response () here in the question, might help to get you answer I guess. – smRaj Oct 16 '13 at 13:48

2 Answers2

1

It could be heap corruption (explaining why malloc terminates the process).

Use your regular tooling to detect undefined behaviour (such as bad memory accesses).

If it's exception handling gone awry (not too unusual in the presence of ABI stressors like cross-compilation), you might use nothrow version of operator new:

X* x = new (nothrow) X;

assert(x); // or otherwise handle with care
sehe
  • 374,641
  • 47
  • 450
  • 633
  • "Use your regular tooling to detect undefined behaviour" . What tools would you recommend to check this kind of possible heap corruptions. I have run valgrind on same code and for the same function MyMsg::operator=() it showed me - " 600 bytes in 1 blocks are still reachable in loss record 26 of 68" which I understood is not necessarily a memory error. Any other tools which could help in analyzing memory errors that you would suggest. – goldenmean Oct 16 '13 at 09:57
  • It's a leak, and indicative of broken value semantics for your classes. Clang has some helpful sanitizer options. – sehe Oct 16 '13 at 10:04
  • Did you mean the valgrind message (600 bytes in 1 blocks are still reachable in loss record 26 of 68) is a leak or this problem of crash could have its roots in a leak? – goldenmean Oct 16 '13 at 10:06
  • The first. And the same root cause is likely to cause other problems, such as your crash. Memory leaks, by itself, don't necessarily break a system (allthough on your ARM box you might run out of memory a lot sooner?) – sehe Oct 16 '13 at 10:16
1

new throws an exception if there is not enough memory left. But there is no exception within the log. So I suppose there is enough memory. The more likely answer is that you have somehow corrupted the memory. You should check your memory accesses with valgrind

What bothers me more is the prototype of the = operator ; MyMsg::operator=(MyPkt*). Why taking a pointer and not a const reference on the object ? Or a least a const MyPkt const *

Davidbrcz
  • 2,335
  • 18
  • 27