Re: [PATCH] Disable the debug.exception-trace sysctl by default

[Andi Kleen <ak@suse.de>]

On Wed, Aug 03, 2005 at 12:39:33PM -0700, Nicholas Miell wrote:
> On Wed, 2005-08-03 at 11:03 +0200, Andi Kleen wrote:
> > On Wed, Jul 27, 2005 at 11:53:30PM -0700, Nicholas Miell wrote:
> > > debug.exception-trace causes a large amount of log spew when on, and
> > > it's on by default, which is an irritation.
> > 
> > > Here's a patch to turn it off.
> > Rejected. 
> 
> Why?

It is supposed to print normally silent segfaults. That improves
quality of software greatly because people actually notice them and
bugs get only fixed when they are noticed.

We started it early with the port, but it is still very useful.

Some misguided distributions unfortunately turn it off by default, but
I think they pay the price in general software quality.


> 
> Getting 5000 lines of
> "inkscape[13137] trap int3 rip:425051 rsp:7fffffa26158 error:0"
> in my logs every time I ltrace something is vastly irritating and serves
> no useful purpose.

Normally it's not supposed to print anything when the process is under control of 
a debugger.  But we made an exception for strace.

Unfortunately that triggers with ltrace because it uses PTRACE_SYSCALL instead
of PTRACE_CONT. 

Anyways, this patch would fix that:


Index: linux/arch/x86_64/mm/fault.c
===================================================================
--- linux.orig/arch/x86_64/mm/fault.c
+++ linux/arch/x86_64/mm/fault.c
@@ -211,9 +211,7 @@ int unhandled_signal(struct task_struct 
 {
 	if (tsk->pid == 1)
 		return 1;
-	/* Warn for strace, but not for gdb */
-	if (!test_ti_thread_flag(tsk->thread_info, TIF_SYSCALL_TRACE) &&
-	    (tsk->ptrace & PT_PTRACED))
+	if (tsk->ptrace & PT_PTRACED)
 		return 0;
 	return (tsk->sighand->action[sig-1].sa.sa_handler == SIG_IGN) ||
 		(tsk->sighand->action[sig-1].sa.sa_handler == SIG_DFL);


> Admittedly, I can (and have) turned this off, but disabling it by
> default will probably save somebody else the trouble of figuring out
> where this crap is coming from and how to kill it.

Giving some other users with the pleasure to figure why things mysteriously
break with silent segfaults. Not a good tradeoff.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/