Sponsored Content
Full Discussion: SCO 5.07 Panic / Core Dumps
Operating Systems SCO SCO 5.07 Panic / Core Dumps Post 302103519 by pankajbraval on Friday 19th of January 2007 04:12:47 AM
Old 01-19-2007
Bug panic

dear ,

i found some time panic and most of memory related problem found
and i am sure it was hw problem. Smilie
 

10 More Discussions You Might Find Interesting

1. UNIX for Advanced & Expert Users

reading core dumps

Does anyone know how to read core dumps. Is gdb the only tool for it ? The OS is Solaris. Thanks (2 Replies)
Discussion started by: suntan
2 Replies

2. Solaris

Generating core dumps

I have the following set up on a Sun server running solaris 5.8 for core dump generation coreadm global core file pattern: /var/core init core file pattern: /var/core global core dumps: enabled per-process core dumps: enabled global setid core dumps:... (4 Replies)
Discussion started by: handak9
4 Replies

3. Programming

strcmp core dumps

hi everyone, Right now when I do: strcmp(s1, s2); i get a core dump because at times s1 or s2 can be nothing so that makes strcmp() core dump. What is the solution, if at times I expect one of them (or both) to be NULL? I want to be able to compare that s1 is NULL and s2 is "blah" or... (6 Replies)
Discussion started by: annie
6 Replies

4. UNIX for Advanced & Expert Users

Using GDB to analyse different CORE dumps

Hi, Can we modify the GDB source code so as to analyze core dumps from different targets? From my analysis, I think we need to build our section table statically for each target. i.e., including the various address boundaries in build_section_table() function. If this is the case, then the GDB... (2 Replies)
Discussion started by: nsdeeps
2 Replies

5. Programming

AIX core dumps

My program is not dumping core when hitting a segmentation violation inside a thread. However, it dumps core when the segv occurs within main. Any ideas on how to diagnose this? AIX 5.3 (4 Replies)
Discussion started by: bean66
4 Replies

6. Solaris

core dumps

i had a situation where a process was defunct. preap would not reap the process and gcore would not work properly (not sure why). therefore, the suggestion was to force a panic and collect the core dump. obviously you could do a savecore -L and capture the dump without bringing down the system.... (3 Replies)
Discussion started by: pupp
3 Replies

7. Ubuntu

enabling core dumps for daemon processes

Hello, I am debugging a program which works as daemon. It sigfaults, unfortunately I'm unable to generate core dump file. Here is what I am doing: tsurko@bastila:~$ ulimit -c unlimited tsurko@bastila:~$ ulimit -c unlimited tsurko@bastila:~$ cat /etc/sysctl.conf | grep 'core_pattern'... (1 Reply)
Discussion started by: tsurko
1 Replies

8. Red Hat

generating core dumps

Hi I have a Fedora installed and I try to generate my application's core dump file. My system has no coredump limit: $ ulimit core file size (blocks, -c) unlimited But when my application crashes no core dumps generated. I can generate dump file using gcore but it is not appropraite... (1 Reply)
Discussion started by: xyzt
1 Replies

9. Programming

Stack only core dumps

I'm working on a program in Linux with a group of people scattered around the country. When we have a crash, I like to send a core dump to the appropriate person so that they can understand the problem better. The problem is that our application uses several gigabytes worth of data and these... (4 Replies)
Discussion started by: bmsterner
4 Replies

10. HP-UX

Generate core dumps

kill -SEGV <pid> gives me the core file for that process but also terminates the process. Can I not get the core dump without terminating the process ? (2 Replies)
Discussion started by: mohtashims
2 Replies
CRASH(8)						    BSD System Manager's Manual 						  CRASH(8)

NAME
crash -- FreeBSD system failures DESCRIPTION
This section explains a bit about system crashes and (very briefly) how to analyze crash dumps. When the system crashes voluntarily it prints a message of the form panic: why i gave up the ghost on the console, and if dumps have been enabled (see dumpon(8)), takes a dump on a mass storage peripheral, and then invokes an automatic reboot procedure as described in reboot(8). Unless some unexpected inconsistency is encountered in the state of the file systems due to hardware or software failure, the system will then resume multi-user operations. The system has a large number of internal consistency checks; if one of these fails, then it will panic with a very short message indicating which one failed. In many instances, this will be the name of the routine which detected the error, or a two-word description of the incon- sistency. A full understanding of most panic messages requires perusal of the source code for the system. The most common cause of system failures is hardware failure, which can reflect itself in different ways. Here are the messages which are most likely, with some hints as to causes. Left unstated in all cases is the possibility that hardware or software error produced the mes- sage in some unexpected way. cannot mount root This panic message results from a failure to mount the root file system during the bootstrap process. Either the root file system has been corrupted, or the system is attempting to use the wrong device as root file system. Usually, an alternate copy of the system binary or an alternate root file system can be used to bring up the system to investigate. Most often this is done by the use of the boot floppy you used to install the system, and then using the ``fixit'' floppy. init: not found This is not a panic message, as reboots are likely to be futile. Late in the bootstrap procedure, the system was unable to locate and execute the initialization process, init(8). The root file system is incorrect or has been corrupted, or the mode or type of /sbin/init forbids execution or is totally missing. ffs_realloccg: bad optim ffs_valloc: dup alloc ffs_alloccgblk: cyl groups corrupted ffs_alloccg: map corrupted blkfree: freeing free block blkfree: freeing free frag ifree: freeing free inode These panic messages are among those that may be produced when file system inconsistencies are detected. The problem generally results from a failure to repair damaged file systems after a crash, hardware failures, or other condition that should not normally occur. A file system check will normally correct the problem. timeout table full This really should not be a panic, but until the data structure involved is made to be extensible, running out of entries causes a crash. If this happens, make the timeout table bigger. init died (signal #, exit #) The system initialization process has exited with the specified signal number and exit code. This is bad news, as no new users will then be able to log in. Rebooting is the only fix, so the system just does it right away. That completes the list of panic types you are likely to see. If the system has been configured to take crash dumps (see dumpon(8)), then when it crashes it will write (or at least attempt to write) an image of memory into the back end of the dump device, usually the same as the primary swap area. After the system is rebooted, the program savecore(8) runs and preserves a copy of this core image and the current system in a specified directory for later perusal. See savecore(8) for details. To analyze a dump you should begin by running kgdb(1) on the system load image and core dump. If the core image is the result of a panic, the panic message is printed. For more details consult the chapter on kernel debugging in the FreeBSD Developers' Handbook (http://www.freebsd.org/doc/en/books/developers-handbook/). SEE ALSO
kgdb(1), dumpon(8), reboot(8), savecore(8) HISTORY
The crash manual page first appeared in FreeBSD 2.2. BSD
July 23, 2011 BSD
All times are GMT -4. The time now is 02:34 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy