This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygthread::cygthread() hang


On Wed, Apr 02, 2003 at 03:23:48PM -0500, Joe Buehler wrote:
>Here's another hang, this time in the cygthread constructor.
>
>The hang shows up in emacs sometimes when a subprocess is run.
>(This might be what an emacs user has reported recently on the
>main mailing list.)  Strace shows the main thread stuck in this routine:
>
>cygthread::cygthread (LPTHREAD_START_ROUTINE start, LPVOID param,
>		      const char *name): func (start), arg (param)
>
>The "sig" thread is trying to send a SIGCHLD and cannot.  I presume that
>this is because the main thread has locked something that prevents
>signals from being delivered.
>
>Strace on the emacs process shows an infinite repeat of this:
>
>   91 1519400614 [sig] emacs 219 wait_sig: awake
>  101 1519400715 [sig] emacs 219 wait_sig: processing signal 20
>   84 1519400799 [sig] emacs 219 wait_sig: Got signal 20
>   83 1519400882 [sig] emacs 219 sig_handle: signal 20
>   87 1519400969 [sig] emacs 219 sig_handle: signal 20, about to call 
>   0x201216FC
>   90 1519401059 [sig] emacs 219 sig_dispatch_pending: pending_signals 1
>   91 1519401150 [sig] emacs 219 sig_dispatch_pending: woke up wait_sig
>  116 1519401266 [sig] emacs 219 setup_handler: couldn't send signal 20
>   93 1519401359 [sig] emacs 219 setup_handler: returning 0
>   88 1519401447 [sig] emacs 219 sig_handle: returning 0
>   90 1519401537 [sig] emacs 219 proc_subproc: args: 3, 0
>  953 1519402490 [sig] emacs 219 proc_subproc: looking for processes to reap
>  199 1519402689 [sig] emacs 219 proc_subproc: finished processing 
>  terminated/stopped child
>   95 1519402784 [sig] emacs 219 proc_subproc: returning 1
>   89 1519402873 [sig] emacs 219 wait_sig: looping
>
>   99 1519402972 [sig] emacs 219 wait_sig: awake
>   83 1519403055 [sig] emacs 219 wait_sig: processing signal 20
>   85 1519403140 [sig] emacs 219 wait_sig: Got signal 20
>   85 1519403225 [sig] emacs 219 sig_handle: signal 20
>   84 1519403309 [sig] emacs 219 sig_handle: signal 20, about to call 
>   0x201216FC
>   88 1519403397 [sig] emacs 219 sig_dispatch_pending: pending_signals 1
>   85 1519403482 [sig] emacs 219 sig_dispatch_pending: woke up wait_sig
>-11057 1519392425 [main] emacs 219 cygthread::cygthread: waiting for 
>(null)<0x0> to become active
>11452 1519403877 [sig] emacs 219 setup_handler: couldn't send signal 20
>  120 1519403997 [sig] emacs 219 setup_handler: returning 0
>   90 1519404087 [sig] emacs 219 sig_handle: returning 0
>   93 1519404180 [sig] emacs 219 proc_subproc: args: 3, 0
>   89 1519404269 [sig] emacs 219 proc_subproc: looking for processes to reap
>   90 1519404359 [sig] emacs 219 proc_subproc: finished processing 
>   terminated/stopped child
>   89 1519404448 [sig] emacs 219 proc_subproc: returning 1
>   91 1519404539 [sig] emacs 219 wait_sig: looping
>
>Here is where the main thread is hung:
>
>  while (!h)
>#ifndef DEBUGGING
>    low_priority_sleep (0);
>#else
>    {
>      system_printf ("waiting for %s<%p> to become active", __name, h);
>      low_priority_sleep (0);
>    }
>
>Both __name and h are null.  The null h is a little odd.  It looks to me
>as if cygthread::new() has allocated a cygthread that has no associated
>windows thread, and is in an infinite loop because of this.
>
>What looks odd to me is that there is a path in cygthread::new() that
>does not set h.  Here is the code in cygthread::new().
>
>  /* Search the threads array for an empty slot to use */
>  for (info = threads; info < threads + NTHREADS; info++)
>    if ((id = (DWORD) InterlockedExchange ((LPLONG) &info->avail, 0)))
>      {
>#ifdef DEBUGGING
>	if (info->__name)
>	  api_fatal ("name not NULL? id %p, i %d", id, info - threads);
>#endif
>	goto out;
>      }
>    else if (!info->id)
>      {
>	info->h = CreateThread (&sec_none_nih, 0, cygthread::stub, info,
>				CREATE_SUSPENDED, &info->id);
>	goto out;
>      }
>
>Is there a problem here because h is not initialized?  Is the strace message
>perhaps a debugging aid to catch this case?

h is only set once when the thread is first started up.  cygthread
threads are persistent to avoid thread creation/exit.

If this is truly a case of h being NULL in the above, then add code to
catch that in the ifdef DEBUGGING case.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]