• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Crash Report
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Crash Report

  • Subject: Re: Crash Report
  • From: Dominic Blais <email@hidden>
  • Date: Fri, 2 Jun 2006 10:17:48 -0700

On Jun 2, 2006, at 10:03 AM, Jim Lloyd wrote:

On Jun 1, 2006, at 12:03 PM, Dominic Blais wrote:

While accessing invalid memory regions (segfault, signal 11) is the most common source of crashing errors in C/C++, there are many other normally unhandled traps that can cause the program to crash (SIGFPE is a notably common one in numerical software).

Yes, but many of these signals do not terminate the process. A better list to look at is from 'man signal', which shows the default action:

No Name Default Action Description
1 SIGHUP terminate process terminal line hangup
2 SIGINT terminate process interrupt program
3 SIGQUIT create core image quit program
4 SIGILL create core image illegal instruction
5 SIGTRAP create core image trace trap
6 SIGABRT create core image abort program (formerly SIGIOT)
7 SIGEMT create core image emulate instruction executed
8 SIGFPE create core image floating-point exception
9 SIGKILL terminate process kill program
10 SIGBUS create core image bus error
11 SIGSEGV create core image segmentation violation
12 SIGSYS create core image non-existent system call invoked
13 SIGPIPE terminate process write on a pipe with no reader
14 SIGALRM terminate process real-time timer expired
15 SIGTERM terminate process software termination signal
16 SIGURG discard signal urgent condition present on socket
17 SIGSTOP stop process stop (cannot be caught or ignored)
18 SIGTSTP stop process stop signal generated from keyboard
19 SIGCONT discard signal continue after stop
20 SIGCHLD discard signal child status has changed
21 SIGTTIN stop process background read attempted from control terminal
22 SIGTTOU stop process background write attempted to control terminal
23 SIGIO discard signal I/O is possible on a descriptor (see fcntl(2))
24 SIGXCPU terminate process cpu time limit exceeded (see setrlimit(2))
25 SIGXFSZ terminate process file size limit exceeded (see setrlimit(2))
26 SIGVTALRM terminate process virtual time alarm (see setitimer(2))
27 SIGPROF terminate process profiling timer alarm (see setitimer(2))
28 SIGWINCH discard signal Window size change
29 SIGINFO discard signal status request from keyboard
30 SIGUSR1 terminate process User defined signal 1
31 SIGUSR2 terminate process User defined signal 2
32 SIGTHR terminate process thread interrupt

Note also that several of the signals that do terminate the process are very unlikely to be the cause of typical "bug crashes": SIGUSR1/2, SIGXCPU, SIGXFSZ, etc.

Please keep in mind that dumping core also means the program crashed. While C/C++ crashes are largely caused by bad pointer access (causing SIGSEGV), many other are quite possible (I can personally attest to having seen many of these over the years). Depending on what you're doing, even the rarer ones pop up -- mishandling internal signal handlers using SIGUSR for example, or process accounting on other unices causing SIGXCPU and SIGXFSZ. Much like errno values, most programming leads only to a few of these constants, but every now and then you will see an EIEIO ( http:// www.gnu.org/software/hurd/faq.en.html#q5-4 ). Okay, maybe not ;)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden
References: 
 >Crash Report (From: Dalton Hamilton <email@hidden>)
 >Re: Crash Report (From: Quinn <email@hidden>)
 >Re: Crash Report (From: David A Rowland <email@hidden>)
 >Re: Crash Report (From: Dominic Blais <email@hidden>)
 >Re: Crash Report (From: Jim Lloyd <email@hidden>)

  • Prev by Date: Re: Crash Report
  • Next by Date: kernel panic
  • Previous by thread: Re: Crash Report
  • Next by thread: kernel panic
  • Index(es):
    • Date
    • Thread