Bug with pthreads

[Joel Sherrill]

Joel Sherrill wrote:
> 
> Peter Pointner wrote:
> >
> > Ok, now i reply to my own mail with a fix. The patch at the end of this
> > message changes the POSIX thread name thing so that it looks like that in
> > the ITRON api. Seem to work.
> 
> I am building this now and will trace in but if you can look at it also
> I would appreciate it.
> 
> When you get to _Thread_Initialize, does the name point to "psx\0" or to
> the address of default_name on the stack.  My reading of this code makes
> me believe the latter.

I believe taking &default_name is wrong.  But what happened where you
saw this?

> Regardless, my first impression is that the name stuff needs to be
> eliminated from
> both pthread.c and pthreadcreate.c.
> 
> I also suspect that other POSIX managers may suffer from having
> unecessary names.

I have confirmed that this is not the case.  Only posix threads have an
arbitrary (and unnecessary) name.  ITRON tasks suffer from the same
behavior.
 
> Comments appreciated.
> 
> > Peter
> >
> > On Tue, 22 Feb 2000, Peter Pointner wrote:
> >
> > > Hello,
> > >
> > > I think there is a bug somewhere in the posix api:
> > >
> > > a) exec/posix/src/pthread.c, _POSIX_Threads_Manager_initialization() calls
> > >    _Objects_Initialize_information with parameter 'is_string' set to TRUE.
> > >
> > > b) exec/posix/src/pthreadcreate.c, pthread_create() defines
> > >       char * default_name = "psx";
> > >    on the stack, then calls
> > >       _Thread_Initialize( ..., &default_name);
> > >
> > > c) exec/score/src/threadinitialize.c, _Thread_Initialize() gives this
> > >    parameter to the macro _Objects_Open
> > >
> > > d) exec/score/macros/rtems/score/object.inl, _Objects_Open() decides
> > >    (based on the information from a) ), to pass this parameter to
> > >    _Objects_Copy_name_string
> > >
> > > e) exec/score/src/objectcopynamestring.c, _Objects_Copy_name_string treats
> > >    the value as pointer to a null terminated string and copies it.
> > >
> > > If I didn't get something wrong, this might lead to unpredictable results,
> > > if this '&default_name' doesn't contain a null byte.
> > >
> > > I'm a bit too confused now to fix that. Any takers?
> > >
> > > Peter
> > >
> >
> > Index: pthread.c
> > ===================================================================
> > RCS file: /m/e2k/rtems-4.5/rtems/c/src/exec/posix/src/pthread.c,v
> > retrieving revision 1.1.1.1
> > diff -u -r1.1.1.1 pthread.c
> > --- pthread.c   2000/02/09 13:23:13     1.1.1.1
> > +++ pthread.c   2000/02/23 10:27:50
> > @@ -356,8 +356,8 @@
> >      FALSE,                               /* does not support global */
> >      maximum_pthreads,
> >      sizeof( Thread_Control ),
> > -    TRUE,
> > -    5,                                   /* length is arbitrary for now */
> > +    FALSE,
> > +    0,                                   /* posix threads don't have a name */
> >      TRUE                                 /* this class is threads */
> >    );
> >
> 
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel at OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985