On Mon, 27 Jul 2015 10:16:04 -0400 Ganesh Ajjanagadde <gajja...@mit.edu> wrote:
> On Mon, Jul 27, 2015 at 10:11 AM, wm4 <nfx...@googlemail.com> wrote: > > On Mon, 27 Jul 2015 08:30:38 -0400 > > Ganesh Ajjanagadde <gajja...@mit.edu> wrote: > > > >> On Mon, Jul 27, 2015 at 7:35 AM, wm4 <nfx...@googlemail.com> wrote: > >> > On Mon, 27 Jul 2015 10:39:16 +0200 > >> > Nicolas George <geo...@nsup.org> wrote: > >> > > >> > > >> >> > + signal(SIGSEGV, sigterm_handler); /* Segmentation fault (ANSI). > >> >> > */ > >> >> > + signal(SIGILL , sigterm_handler); /* Invalid instruction (ANSI). > >> >> > */ > >> >> > + signal(SIGFPE , sigterm_handler); /* Arithmetic error (ANSI). > >> >> > */ > >> >> > >> >> NO!!! > >> >> > >> >> When a crash happens, we want it to happen right there, possibly leave a > >> >> core. We do not want a signal handler to mess up the remains. > >> > > >> > +1 > >> > > >> >> > #ifdef SIGXCPU > >> >> > signal(SIGXCPU, sigterm_handler); > >> >> > #endif > >> > > >> > Why? > >> > >> Not sure; note this was not added by me. > >> From Kerrisk's "Linux Programming Interface" book, > >> SIGXCPU is raised when CPU limit is exceeded. > >> It is a Linux thing, relevant when RLIMIT_CPU is set. > > > > You shouldn't just copy paste things you don't understand. > > As I mentioned above, this was not part of my patch at all. > Since you asked why, I looked it up out of curiousity and gave > information that I could find. > I felt this would be useful to others on this list as well, and cite a > source for reference. > Therefore, I do not see what the trouble is in posting it to the discussion, > especially since I prefaced it with a "not sure". Oops, I see, sorry about that. I overreacted and missed that bit. These lines of code comes from commit ffcc6e24f5dfa9 and are basically absurd non-sense. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
