Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
If the program failed with an error SIGFAULT, and no progress to debug, what shall I do now? Like this:
---------------------------------------------------------------
% gdb ico
...
(gdb) r
Starting program: .../ico
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
You can't do that without a process to debug.
(gdb) bt
No stack.
(gdb) q
----------------------------------------------------------------
After type
% ico
I got a core dump
And then I
% gdb ico core*
...
But I didn't see any information useful.
Could anyone give me some favor, I really appreciate it.
When you have loaded the program and it's core dump, do a backtrace to see where the program failed. The command is bt. You can change the stack frame with the frame command. For example, I made a little test program called t which calls a function called "myfunc" which causes a SEGFAULT:
Code:
% cat t.c
#include <stdlib.h>
#include <string.h>
int myfunc() {
char* flart=NULL;
memcpy(flart, "BANANAS", 8);
return 1;
}
int main()
{
myfunc();
return 0;
}
% gcc -g t.c -o t
% ulimit -c unlimited
% ./t
Segmentation fault (core dumped)
% ls -l core
-rw------- 1 matthew matthew 143360 2007-12-05 18:02 core
% gdb t core
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/tls/i686/cmov/libc.so.6...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `./t'.
Program terminated with signal 11, Segmentation fault.
#0 0x08048354 in myfunc () at t.c:6
6 memcpy(flart, "BANANAS", 8);
(gdb) bt
#0 0x08048354 in myfunc () at t.c:6
#1 0x0804837b in main () at t.c:12
(gdb) l
1 #include <stdlib.h>
2 #include <string.h>
3
4 int myfunc() {
5 char* flart=NULL;
6 memcpy(flart, "BANANAS", 8);
7 return 1;
8 }
9
10 int main()
(gdb) frame 1
#1 0x0804837b in main () at t.c:12
12 myfunc();
(gdb) l
7 return 1;
8 }
9
10 int main()
11 {
12 myfunc();
13
14 return 0;
15 }
16
(gdb) quit
So you can see where the program crashed, and it should be clear that it is because of the memcpy function, any why.
Infact my program is a very big one. I can successfully compile and run it under any linux without much trouble.
but on Irix, idon't know what I am missing, I was caught here.
Now, I don't even know what shall I do.
I will post the detailed description here, but 1st, I want to tell that I really hope i can do a bt command, but if it said in gdb:
You can't do that without a process to debug.
then how can I do any bt or other gdb-command?
that's strange, and what makes me headache about.
Here's the detailed description:
Quote:
onyx-bridge 1% uname -a
IRIX64 onyx-bridge 6.5 01080747 IP35
onyx-bridge 2% which blockMesh
/disk4/usr/people/student3/OpenFOAM/OpenFOAM-1.4.1/applications/bin/sgiN32GccDPDebug/blockMesh
onyx-bridge 3% blockMesh
Segmentation fault (core dumped)
onyx-bridge 4% gdb blockMesh core
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "mips-sgi-irix6.5"...
Reading symbols from /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libmeshTools.so...done.
Loaded symbols for /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libmeshTools.so
Reading symbols from /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libtriSurface.so...done.
Loaded symbols for /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libtriSurface.so
Reading symbols from /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/liblagrangian.so...done.
Loaded symbols for /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/liblagrangian.so
Reading symbols from /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libfiniteVolume.so...done.
Loaded symbols for /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libfiniteVolume.so
Reading symbols from /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libPstream.so...done.
Loaded symbols for /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libPstream.so
Reading symbols from /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libdynamicMesh.so...done.
Loaded symbols for /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libdynamicMesh.so
Reading symbols from /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libOpenFOAM.so...done.
Loaded symbols for /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libOpenFOAM.so
Reading symbols from /usr/lib32/libfpe.so...done.
Loaded symbols for /usr/lib32/libfpe.so
Reading symbols from /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libstdc++.so.6...done.
Loaded symbols for /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libstdc++.so.6
Reading symbols from /usr/lib32/libm.so...done.
Loaded symbols for /usr/lib32/libm.so
Reading symbols from /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libgcc_s.so.1...done.
Loaded symbols for /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libgcc_s.so.1
Reading symbols from /usr/lib32/libc.so.1...done.
Loaded symbols for /usr/lib32/libc.so.1
Reading symbols from /usr/lib32/libz.so...done.
Loaded symbols for /usr/lib32/libz.so
You can't do that without a process to debug.
(gdb) r
Starting program: /disk4/usr/people/student3/OpenFOAM/OpenFOAM-1.4.1/applications/bin/sgiN32GccDPDebug/blockMesh
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
You can't do that without a process to debug.
(gdb) l 1
You can't do that without a process to debug.
(gdb) bt
You can't do that without a process to debug.
(gdb) q
onyx-bridge 5% gdb blockMesh
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "mips-sgi-irix6.5"...
(gdb) r
Starting program: /disk4/usr/people/student3/OpenFOAM/OpenFOAM-1.4.1/applications/bin/sgiN32GccDPDebug/blockMesh
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
You can't do that without a process to debug.
(gdb) r 1
Starting program: /disk4/usr/people/student3/OpenFOAM/OpenFOAM-1.4.1/applications/bin/sgiN32GccDPDebug/blockMesh 1
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
You can't do that without a process to debug.
(gdb) l 1
1 /*---------------------------------------------------------------------------*\
2 ========= |
3 \\ / F ield | OpenFOAM: The Open Source CFD Toolbox
4 \\ / O peration |
5 \\ / A nd | Copyright (C) 1991-2007 OpenCFD Ltd.
6 \\/ M anipulation |
7 -------------------------------------------------------------------------------
8 License
9 This file is part of OpenFOAM.
10
(gdb) b 15
Breakpoint 1 at 0x10055368: file genBlockMesh.C, line 15.
(gdb) r
Starting program: /disk4/usr/people/student3/OpenFOAM/OpenFOAM-1.4.1/applications/bin/sgiN32GccDPDebug/blockMesh 1
To do a backtrace, you need either a running (but stopped) process in memory, or a core file. The core file is essentially a dump of the process state at the time it crashed.
Does the core file actually exist? When you see the "Segmentation fault (core dumped)" message, it can be mis-leading, because if the core file size limit is set to 0, it will not create one despite the message.
Before you run the program, make sure the core size limit is set to unlimited, and that you have enough disk space / quota to create it (it might be very large):
Code:
ulimit -c unlimited
Then run the program, and verify that the core file has been produced. After the core file has been created, you should also check that the disk still has space left:
Code:
df -h .
If it says 100% in the usage column, free up some space and try again.
If you operate on a system with disk quotas enabled, you should also verify the you are not bumping up against the quota limit (use the quota -v command to check).
If you're sure the core file is not being truncated by limited space, then run gdb.
Of course, your application also needs to have been built using the -g option to gcc to include debugging symbols, else gdb won't be able to make any sense of it.
Another approach is to run the program from within gdb, and after the segv, then just type "bt". If you still get this message at that point, then I'm afraid I have no idea what is happening.
I really appreciate your help, Matthew.
I did all that according to what you told me, and the outcome is the same
Quote:
onyx-bridge 4% gdb blockMesh core
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "mips-sgi-irix6.5"...
Reading symbols from /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libmeshTools.so...done.
Loaded symbols for /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libmeshTools.so
Reading symbols from /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libtriSurface.so...done.
Loaded symbols for /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libtriSurface.so
Reading symbols from /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/liblagrangian.so...done.
Loaded symbols for /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/liblagrangian.so
Reading symbols from /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libfiniteVolume.so...done.
Loaded symbols for /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libfiniteVolume.so
Reading symbols from /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libPstream.so...done.
Loaded symbols for /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libPstream.so
Reading symbols from /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libdynamicMesh.so...done.
Loaded symbols for /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libdynamicMesh.so
Reading symbols from /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libOpenFOAM.so...done.
Loaded symbols for /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libOpenFOAM.so
Reading symbols from /usr/lib32/libfpe.so...done.
Loaded symbols for /usr/lib32/libfpe.so
Reading symbols from /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libstdc++.so.6...done.
Loaded symbols for /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libstdc++.so.6
Reading symbols from /usr/lib32/libm.so...done.
Loaded symbols for /usr/lib32/libm.so
Reading symbols from /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libgcc_s.so.1...done.
Loaded symbols for /disk4/usr/people/student3/OpenFOAM/sgiN32/gcc-4.2.1/lib32/libgcc_s.so.1
Reading symbols from /usr/lib32/libc.so.1...done.
Loaded symbols for /usr/lib32/libc.so.1
Reading symbols from /usr/lib32/libz.so...done.
Loaded symbols for /usr/lib32/libz.so
You can't do that without a process to debug.
this is exactly what my outcome is.
And could anyone help me!
The common theme seems to be gdb running on IRIX or some Windows systems. I would recommend taking it up with the gdb project directly. There may be a patch which fixes it, or they might be able to direct you to a known-good older version of gdb on your platform.
Last edited by matthewg42; 12-10-2007 at 05:12 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.