[Bug 1764] RTEMS shell not always waiting for termination

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1764

--- Comment #4 from dufault at hda.com 2011-03-17 06:18:56 CDT ---
(In reply to comment #3)
> (In reply to comment #2)
> > Another possibility is that it isn't a second shell starting up but somehow two
> > calls to my  POSIX_Init() resulting in two calls to my main_thread starting two
> > shells. 
> 
> A static variable incremented would help here.
Or for completeness, even a mutex.  At least it would protect against a second
call to my POSIX_Init(), which I'm definitely not expecting, and it would
provide a work-around for now.

> 
> >     rtems_bsdnet_initialize_network();
> >     rtems_telnetd_initialize();
> 
> Could it be a telnet shell init failing some how and the shell ending up on the
> console ?
I don't think so.  The two tasks are named SHLC:

> 0a010006   SHLC           100 READY  P:T:nA    NONE   1a010004 0x210a28a8       
> 0a010007   SHLC           100 READY  P:T:nA    NONE   1a010004 0x210a28a8       

telnet started it's daemon:
> 0a010004   TNTD           100 Wevnt  P:T:nA    NONE   55655191 0x210a28a8       

and I don't have access to an RTEMS system right now to test this, but it
appears a spawned TELNET task will have the name 'XXXX'.  In
telnetd_dflt_spawn():
  char                     nm[4] = {'X','X','X','X' };

How are classic API events allocated?  When the shell-starter is going to wait
for a spawned shell to finish it waits on RTEMS_EVENT_1 after starting the
shell thread without any check whether the event is already pending or not.  If
there's a pending RTEMS_EVENT_1 it would return right away, resulting in the
behavior I'm seeing.  I'm not familiar with the RTEMS events, I guess they are
a per-task bit map.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.