From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-30151-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 9684 invoked by alias); 9 Nov 2007 04:38:27 -0000
Received: (qmail 9675 invoked by uid 22791); 9 Nov 2007 04:38:27 -0000
X-Spam-Check-By: sourceware.org
Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 09 Nov 2007 04:38:25 +0000
Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) 	by smtp-out.google.com with ESMTP id lA94cFjT011590 	for <gdb@sourceware.org>; Fri, 9 Nov 2007 04:38:16 GMT
Received: from ug-out-1314.google.com (ugg36.prod.google.com [10.66.7.36]) 	by zps19.corp.google.com with ESMTP id lA94cEaS021837 	for <gdb@sourceware.org>; Thu, 8 Nov 2007 20:38:15 -0800
Received: by ug-out-1314.google.com with SMTP id 36so441987ugg         for <gdb@sourceware.org>; Thu, 08 Nov 2007 20:38:14 -0800 (PST)
Received: by 10.66.248.5 with SMTP id v5mr189518ugh.1194583093861;         Thu, 08 Nov 2007 20:38:13 -0800 (PST)
Received: by 10.67.21.14 with HTTP; Thu, 8 Nov 2007 20:38:13 -0800 (PST)
Message-ID: <e394668d0711082038r412087eaj3b0cda56cdddaff0@mail.gmail.com>
Date: Fri, 09 Nov 2007 04:38:00 -0000
From: "Douglas Evans" <dje@google.com>
To: gdb@sourceware.org
Subject: linux-thread-db.c not only caller of add_thread, -> gdb segv
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2007-11/txt/msg00063.txt.bz2

Hi. I'm trying to decide what's the best way to fix a bug I've found.
linux-thread-db.c is not the only caller of add_thread, e.g. infrun.c
calls it too.
linux-thread-db.c assumes thread_info.private is non-NULL, e.g. here:

static int
clear_lwpid_callback (struct thread_info *thread, void *dummy)
{
  /* If we know that our thread implementation is 1-to-1, we could
save
     a certain amount of information; it's not clear how much, so we
     are always conservative.  */

  thread->private->th_valid = 0;
  thread->private->ti_valid = 0;

  return 0;
}

called from here:

#0  0x00000000004681a4 in clear_lwpid_callback (thread=0xb132d0,
dummy=0x0) at ../../src/gdb/linux-thread-db.c:765
#1  0x00000000004f8480 in iterate_over_threads (callback=0x46818d
<clear_lwpid_callback>, data=0x0) at ../../src/gdb/thread.c:204
#2  0x00000000004682a6 in thread_db_resume (ptid={pid = -1, lwp = 0,
tid = 0}, step=0, signo=TARGET_SIGNAL_0) at
../../src/gdb/linux-thread-db.c:782
#3  0x00000000004eb83d in resume (step=0, sig=TARGET_SIGNAL_0) at
../../src/gdb/infrun.c:614
#4  0x00000000004ebc14 in proceed (addr=18446744073709551615,
siggnal=TARGET_SIGNAL_DEFAULT, step=0) at ../../src/gdb/infrun.c:805

This is iterating over all threads, some of which were created via
add_thread calls outside of linux-thread-db.c, and thus
thread_info.private is NULL and boom, segv.

I can see two solutions
1) ensure all calls to add_thread properly initialize thread_info.private
   (via callback or whatever)
2) have linux-thread-db.c always check thread_info.private before
dereferencing it.

Comments?