Re: Thread exit error : gdb7.2 in FreeBSD (built from ports)

[John Schumacher <schumjs at gmail dot com>]

On Thu, 2011-09-22 at 17:06 -0500, John Schumacher wrote:
> 
> This is very suspicious. Is FreeBSD calling into gdb twice for an
> exiting thread? The first time, we are flagging it as exited, and
> getting caught up in the get_current_frame() the second time?
> 
> 
> Is fbsd-threads.c the one who is calling into gdb? Or how does that
> relationship work?
> Thanks again
> -John
> -- 
> John Schumacher
> 
> 

I have questions about the following areas of code within fbsd-threads.c

static ptid_t
fbsd_thread_wait (struct target_ops *ops,
		  ptid_t ptid, struct target_waitstatus *ourstatus, int options)
{
....
      if (ourstatus->value.sig == TARGET_SIGNAL_TRAP)
        check_event(ret);
      /* this is a hack, if an event won't cause gdb to stop, for
example,
         SIGARLM, gdb resumes the process immediatly without setting
         inferior_ptid to the new thread returned here, this is a bug
         because inferior_ptid may already not exist there, and passing
         a none existing thread to fbsd_thread_resume causes error. */
      if (!fbsd_thread_alive (ops, inferior_ptid))
        {
          delete_thread (inferior_ptid);
          inferior_ptid = ret;
        }
    }

  return (ret);
}

Don't we already notify gdb of this through handle_inferior_event? Why
should fbsd-threads.c do this on its own? 
When debugging I saw the following:  we remove the thread here, but
later then an execution_control_state is still created for
handle_inferior_event for the exiting lwp ( or thread, it's used
ambiguously in the case of 1:1 threading) with stop_func_name =
0x8018c13c5 "_thread_bp_death" for the exiting thread. As the thread
state is '_exiting', we will then get hosed later when we handle this as
it checks get_current_frame() (which has an error if the thread state ==
exiting) and forces the user to have to switch to a different thread.

When this delete is commented out, threads are still being properly
removed and no error()'s are occurring. Can you shed any light on the
condition that it is talking about?

(Hopefully this message will pass through without modification, I'm
using plain-text)