CODEWITHSUNDEEP
cdebuggingstackcoredumpcorrupt
bob
bob

Reputation:

segmentation fault on Unix - possible stack corruption

i'm looking at a core from a process running in Unix. Usually I can work my around and root into the backtrace to try identify a memory issue. In this case, I'm not sure how to proceed.

Firstly the backtrace only gives 3 frames where I would expect alot more. For those frames, all the function parameters presented appears to completely invalid. There are not what I would expect.

Some pointer parameters have the following associated with them - Cannot access memory at address

Would this suggest some kind of complete stack corruption. I ran the process with libumem and all the buffers were reported as being clean.

umem_status reported nothing either.

so basically I'm stumped. What is the likely causes? What should I look for in code since libumem appears to have reported no errors.

Any suggestions on how I can debug furhter? any extra features in mdb I should consider?

thank you.

Upvotes: 3

Views: 1816

Answers (5)

Prabhu. S
Prabhu. S

Reputation: 1793

I did run into similar issue. The backtrace from GDB was not helpful. Valgrind came to my rescue.

Run your application through Valgrind. Identify all the errors like invalid writes. Analyze the piece of code and see if they can be fixed.

In my case I was attempting a invalid write(which at times might write NULL) which showed its effect not at that instance but else where.

Upvotes: 0

gbarry
gbarry

Reputation: 10554

Your code? When this happens to me, I always find the same thing: A null pointer. Looks horrible when it crashes, but the cause is ultimately simple.

Upvotes: 0

bob
bob

Reputation:

shouldnt libumem report the same overrun as electric fence?

can't reproduce easy in test environment but in commercial env under unix/solaris the core occurs but libumem shows nothing bad,

Upvotes: 0

dwc
dwc

Reputation: 24910

Stack corruption does sound like a possibility. Some things to try:

  • Turn on all compiler warnings that you can!
  • Run lint!
  • If possible, try building & testing your program on OpenBSD which has a lot of memory corruption detection built-in.
  • If possible, use some tools like ProPolice, StackGuard, et al.
  • If you can reproduce this problem easily, it's worth playing around in the debugger. Narrow it down as much as possible and then step through.

Upvotes: 4

epatel
epatel

Reputation: 46041

You can look into if using Valgrind or ElectricFence could break a little earlier for you.

Upvotes: 3

Related Questions