LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (https://www.linuxquestions.org/questions/programming-9/)
-   -   Program received signal SIGSEGV, Segmentation fault (https://www.linuxquestions.org/questions/programming-9/program-received-signal-sigsegv-segmentation-fault-578845/)

go939 08-22-2007 12:01 AM

Program received signal SIGSEGV, Segmentation fault
 
hey there!

I'm trying to debug my program. i use the gdb as my debugging application. first i link all my source codes using make (makefile), then i use gdb test to debug the program. after which, i use the run command [ (gdb) run] to check for any possible error on my program. below are the result messages:

Starting program:
[Thread debugging using libthread_db enabled]
[New Thread - 1211099440 (LWP 5322)]

Program received signal SIGSEV, segmentation fault
[switching to thread - 1211099440 (LWP 5322)
0xb7f73442 in pthread_cond_destroy@@GLIBC_2.3.2

Can somebody explain to me what does this mean?
I'm just a newbie user of gdb.

Thanks a lot!

wjevans_7d1@yahoo.co 08-22-2007 12:36 AM

Wow.

Where to begin?

First, I imagine that you typed the output by hand, because that should not be SIGSEV, but SIGSEGV. SIG stands for signal. For more information, google this:
Code:

Unix signal tutorial
SEGV stands for segment violation. Your program died because it tried to use a memory pointer that didn't point to a valid segment of memory. This can happen for several reasons. Here are some of the more, um, popular ones:
  1. The value in the pointer itself is NULL (usually all zero bits), which is a special value reserved to indicate that the pointer doesn't point anywhere.
  2. The value was derived by calculating some subscript in an array of data, and the subscript is either negative or too high, outside the bounds of the array (usually way too far outside).
  3. Some time ago the pointer may have had a valid value, but some part of the program stomped on the pointer; that is, it moved quite valid data to an invalid place in memory, and that invalid place in memory happens to be the pointer in question.
You'll need to learn much about gdb. To do so, go here.

Further, it's evident from the output that you're debugging a program using POSIX threads. If you are discovering at this point what SIGSEGV means, and you're already debugging a POSIX threads program, you're in an unenviable position.

May I ask whether you wrote this program yourself or whether it's an older program you're being asked to debug as part of your job, or what?

go939 08-22-2007 12:45 AM

yap...type-error...

about the source code, I ported a source from win32 to C++ in Linux platform. There is already a source code from win32, so my work is to port the program in linux.

Thanks for your help.

Quigi 08-22-2007 11:06 AM

When gdb says "Program received SIGSEGV", you could type "where" -- it should spit out a list of which function called which. That may tell you which part of your program called pthread_cond_destroy -- directly or indirectly. But for case 3 (some other part of the program stomped the pointer) that won't help that much.

You could also give valgrind a quick try. It's usually used to find memory leaks (not your problem here), but it's quite good at reporting other suspicious things going on with your memory. It's not certain to find the problem, but not much effort to try.

exvor 08-22-2007 06:54 PM

Yeah I second the recommendation to try valgrind. It helped me figure out a strange segfault in my own application.


All times are GMT -5. The time now is 05:25 AM.