Program received signal SIGSEGV, Segmentation fault.


 
Thread Tools Search this Thread
Top Forums Programming Program received signal SIGSEGV, Segmentation fault.
Prev   Next
# 1  
Old 06-03-2006
Program received signal SIGSEGV, Segmentation fault.

Dear all,

I used debugger from C++ and these are the message I got:

Program received signal SIGSEGV, Segmentation fault.
0x00323fc0 in free () from /lib/tls/libc.so.6
(gdb) info s
#0 0x00323fc0 in free () from /lib/tls/libc.so.6
#1 0x00794fa1 in operator delete () from /usr/lib/libstdc++.so.6
#2 0x080d3934 in matvec::MIM::release (this=0xbfe8e710) at mim.cpp:49
#3 0x0805f57c in ~MIM (this=0xbfe8e710) at mim.h:120
#4 0x0805eedc in main () at analysis.cpp:199

I think the problem comes from "free () from /lib/tls/libc.so.6" but I don't know what it means and how to fix it. Smilie I heard that "installing libc is not trivial". I am not sure if I have to install "libc".

Could somebody educate me what the error mean and how to fix it? I know very little about Linux but I am willing to learn.

Thank you for your help.
 
Login or Register to Ask a Question

Previous Thread | Next Thread

8 More Discussions You Might Find Interesting

1. Programming

Using gdb, ignore beginning segmentation fault until reproduce environment segmentation fault

I use a binary name (ie polo) it gets some parameter , so for debugging normally i do this : i wrote script for watchdog my app (polo) and check every second if it's not running then start it , the problem is , if my app , remain in state of segmentation fault for a while (ie 15 ... (6 Replies)
Discussion started by: pooyair
6 Replies

2. Programming

Segmentation fault in other systems C program

Hello everybody, I've been working on a program on my Linux box, after finished the code, i compile it with gcc -Wall option, so i can see what's wrong or unused. The Walll output shows nothing, so there are no loose ends on the program. I run the program on my system, and it works PERFECTLY.... (5 Replies)
Discussion started by: Zykl0n-B
5 Replies

3. Programming

Why do I receive Program received signal SIGABRT, Aborted?

Im using gdb and when a user disconnects from my server I receive a message Program received signal SIGABRT, Aborted. 0x7ffe0304 in ?? () I was hoping someone here might have a explination for this message in gdb (26 Replies)
Discussion started by: Errigour
26 Replies

4. Programming

Program received signal: “EXC_BAD_ACCESS”?

I am making a command line program in C using XCode. When running the program, it initially does what it is supposed to do (asks me for a file path). However, when I type in a valid and existing file path, it gives me the following error: Program received signal: “EXC_BAD_ACCESS”.... (6 Replies)
Discussion started by: mdonova33
6 Replies

5. Programming

getting Segmentation Fault (core dumped) error but Program runs fine.

i am executing following program int main() { char str; FILE * fp; int i=0; ... (4 Replies)
Discussion started by: bhavesh.sapra
4 Replies

6. AIX

Received signal #11, SIGSEGV [default] on AIX 6.1

Hello, One of our customer is getting segmentation fault when he runs his shell script which invokes our executable on AIX 6.1. On AIX 5.3, there were no issues. Here is the truss output. 811242: __loadx(0x0A040000, 0xF0D3A26C, 0x00000000, 0x00000009, 0x00000000) = 0xF026E884... (0 Replies)
Discussion started by: erra_krishna
0 Replies

7. Programming

SIGSEGV, Segmentation fault

Here is my initiating code: #define NUM 20 static struct tab { int count; int use; } tab; int curtab = 0; int tab_create(int tab_count) { curtab++; tab.use = 1; tab.count = tab_count; kprintf("here!"); return curtab; } (2 Replies)
Discussion started by: micmac700
2 Replies

8. Programming

Program received signal SIGABRT, Aborted.

I ran degugger in C++ and the followings are the message I got: Program received signal SIGABRT, Aborted. 0x002a57a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) info s #0 0x002a57a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x002e97f5 in raise () from /lib/tls/libc.so.6... (1 Reply)
Discussion started by: napapanbkk
1 Replies
Login or Register to Ask a Question
xpc_abort(3)						   BSD Library Functions Manual 					      xpc_abort(3)

NAME
xpc_abort -- conditions which cause XPC to abort DESCRIPTION
The XPC API will aggressively defend itself against perceived misuse. Wherever XPC can definitively detect misuse of its APIs or data corrup- tion, it will abort. For example, if the retain count of an object underflows by calling xpc_release(3) on it too many times, XPC will abort the process. Many frameworks opt to keep the program limping along in such a state (and will perhaps print a warning message to the system log), but aborting upon detection provides unmistakable warning that there is a bug present in the application which should be fixed before shipping. When XPC aborts a process, it will place information about the condition which triggered the abort in the Application Specific Information section of the crash report. The message will be human-readable, prefixed with "XPC API Misuse:", and the crash report will indicate the stack trace which caused the abort. XPC will also abort if it detects unrecoverable data corruption in its internal state. The messages for these conditions will be prefixd with "Bug in libxpc:". If you come across such a crash, please file a bug and include the generated crash log, system log and steps to reproduce (if there are any identifiable steps). Currently, the manner in which XPC aborts the process will result in termination due to SIGILL (illegal instruction). The exact signal raised may change from release to release (or platform to platform). But on OS X Lion, SIGILL may be used as a hint that the process was terminated intentionally. DEBUGGING
When debugging in Xcode or at the gdb command prompt, the debugger acts as the exception handler for the process being debugged. As a result, if the process is aborted by XPC, no crash report will be generated, and thus it may not be obvious why the program was terminated. As mentioned before, SIGILL is an indication that the process was terminated intentionally. If you observe the last frame in the crashing stack to be _xpc_api_misuse(), you may use the xpc_debugger_api_misuse_info() API from within the debugger to obtain a human-readable string describing why the process was aborted. For example: Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand. 0x000000010012b25e in _xpc_api_misuse () (gdb) p (char *)xpc_debugger_api_misuse_info() $1 = 0x7fff5fbff908 "XPC API Misuse: Over-release of object." (gdb) This message indicates that xpc_release(3) was called too many times on an object. IMPORTANT: The xpc_debugger_api_misuse_info() API can ONLY be called from within a debugger. It is not meant to be called directly from the program. Do not call it directly from your code, and do not rely on the address of the result for any reason. SEE ALSO
xpc(3), xpc_object(3), xpc_objects(3) Darwin 1 July, 2011 Darwin