From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26875 invoked by alias); 7 Mar 2010 15:25:58 -0000 Received: (qmail 26867 invoked by uid 22791); 7 Mar 2010 15:25:57 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 07 Mar 2010 15:25:53 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 1509F2BAB4F for ; Sun, 7 Mar 2010 10:25:52 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lOcNGIO2vF0w for ; Sun, 7 Mar 2010 10:25:52 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 4DC972BAB4E for ; Sun, 7 Mar 2010 10:25:51 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 82783F5894; Sun, 7 Mar 2010 19:25:31 +0400 (RET) From: Joel Brobecker To: gdb-patches@sourceware.org Subject: [commit/RFA] Avoid switch to invalid ptid during Ada task switch. Date: Sun, 07 Mar 2010 15:25:00 -0000 Message-Id: <1267975529-28959-1-git-send-email-brobecker@adacore.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-03/txt/msg00273.txt.bz2 Hello, This is a followup on something I mentioned in an earlier email: http://www.sourceware.org/ml/gdb-patches/2010-03/msg00272.html The goal is to prevent an internal error during an Ada task switch. A task switch is simply a thread switch under the hood. What we do is collect the info from the Ada Task Control Block, deduce the associated thread ptid, and then switch to that thread. If the thread ptid computation routine has not been implemented for the target, of if there is a bug, then we end up computing a bogus ptid which GDB does not know about, which eventually leads to an assertion failure: (gdb) task 1 [New Thread 5715] /[...]/gdb/thread.c:595: internal-error: is_thread_state: Assertion `tp' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) When this happens, it's just nicer for the user to print an error message, and cancel the task switch. After this patch is applied, this is what we get: (gdb) task 1 [New Thread 10250] Unable to compute thread ID for task 1. Cannot switch to this task. What do you guys think? Is the wording OK? gdb/ChangeLog: * ada-tasks.c (task_command_1): Check that the task ptid is valid before doing the associated thread switch. Tested on x86_64-linux. No regression. I was thinking of applying this to head, and maybe the branch as well. But I'll wait for a couple of days in care there are some suggestions. --- gdb/ada-tasks.c | 13 +++++++++++++ 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/gdb/ada-tasks.c b/gdb/ada-tasks.c index be9b8e6..519cfc6 100644 --- a/gdb/ada-tasks.c +++ b/gdb/ada-tasks.c @@ -877,6 +877,19 @@ task_command_1 (char *taskno_str, int from_tty) to the thread list. */ target_find_new_threads (); + /* Verify that the ptid of the task we want to switch to is valid + (in other words, a ptid that GDB knows about). Otherwise, we will + cause an assertion failure later on, when we try to determine + the ptid associated thread_info data. We should normally never + encounter such an error, but the wrong ptid can actually easily be + computed if target_get_ada_task_ptid has not been implemented for + our target (yet). Rather than cause an assertion error in that case, + it's nicer for the user to just refuse to perform the task switch. */ + if (!find_thread_ptid (task_info->ptid)) + error (_("Unable to compute thread ID for task %d.\n" + "Cannot switch to this task."), + taskno); + switch_to_thread (task_info->ptid); ada_find_printable_frame (get_selected_frame (NULL)); printf_filtered (_("[Switching to task %d]\n"), taskno); -- 1.6.3.3