[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gdb
Subject:    Re: when can find_thread_pid (inferior_ptid) return NULL?
From:       Doug Evans <dje () google ! com>
Date:       2009-03-27 0:53:53
Message-ID: e394668d0903261753u761c03b8g896aa4374911fabe () mail ! gmail ! com
[Download RAW message or body]

On Thu, Mar 26, 2009 at 3:35 PM, Pedro Alves <pedro@codesourcery.com> wrote:
> On Thursday 26 March 2009 21:36:42, Doug Evans wrote:
>> Hi.  Some places in gdb assert that find_thread_pid (inferior_ptid)
>> is never NULL.
>
>> make_cleanup_restore_current_thread:
>>
>>       tp = find_thread_pid (inferior_ptid);
>>       if (tp)
>>       tp->refcount++;
>
> I think that in this particular case, it will always be true.
>
>>
>> Since delete_thread_1 has this:
>>
>>   /* If this is the current thread, or there's code out there that
>>      relies on it existing (refcount > 0) we can't delete yet.  Mark
>>      it as exited, and notify it.  */
>>   if (tp->refcount > 0
>>       || ptid_equal (tp->ptid, inferior_ptid))
>>     {
>>
>> I would expect that one can always assert
>> find_thread_pid (inferior_ptid) != NULL.
>>
>> Is that true?
>> Or are there situations where it's not true?
>
> When inferior_ptid is null_ptid.  You'll also not
> find the old ptid if running the cleanup after something
> clears the thread list, e.g., after killing or poping the target.

Ya, I found that out shortly after ^c^c.  What a surprise.  :-)

[prev in list] [next in list] [prev in thread] [next in thread]