linux-mips
[Top] [All Lists]

Re: unkillable process due to setup_frame() failure

To: ralf@linux-mips.org
Subject: Re: unkillable process due to setup_frame() failure
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Wed, 07 Sep 2005 23:44:13 +0900 (JST)
Cc: macro@linux-mips.org, linux-mips@linux-mips.org
In-reply-to: <20050907134717.GA3493@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20050906184118.GC3102@linux-mips.org> <Pine.LNX.4.61L.0509071011560.4591@blysk.ds.pg.gda.pl> <20050907134717.GA3493@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
>>>>> On Wed, 7 Sep 2005 14:47:17 +0100, Ralf Baechle <ralf@linux-mips.org> 
>>>>> said:

ralf> That said, I definately prefer the approach of Atushi's
ralf> suggested fix #2.  The other question is why we try to continue
ralf> if delivering a signal failed and we already know that repeated
ralf> attempts would fail again.

The question is for my fix #1 ?

Well, let me explain more.  With that fix, things will go like this:

1.  The "break" instruction raises a exception.
2.  The exception handler queues SIGTRAP(5).
3.  dequeue_signal() dequeue a signal with LOWEST number (i.e. SIGTRAP).
4.  setup_frame() fails due to bad stack pointer and queues SIGSEGV(11).
5.  do_signal() called again (by fix #1)
6.  dequeue_signal() dequeue a signal (i.e. SIGSEGV).
7.  If SIGSEGV did not have a signal handler, default action (coredump
    and exit) is taken.  End.
8.  If SIGSEGV had a signal handler, setup_frame() fails and queues
    SIGSEGV again.  It resets SIGSEGV's handler to SIG_DFL.
9.  returns to user process (pc unchanged).
10.  goto 1.  Then ended at 7.

My fix #2 is more generic approach, but even with the fix, the test
program eats CPU until killed by SIGKILL.  With my fix #1, the test
program will exit immediately.  

So my "which is preferred" question was inappropriate.  I had to ask
"#1 or #2 or both or other ?"

---
Atsushi Nemoto

<Prev in Thread] Current Thread [Next in Thread>