[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bug with pthreads



On Wed, 23 Feb 2000, Joel Sherrill wrote:

> 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?

After thinking about it, I believe it simply does not matter what value is
passed here. (This is true _after_ applying the patch below, of course).
The patch makes Object_Open call _Objects_Copy_name_raw with a length of
0, so nothing is copied. Maybe NULL should be passed instead of
&default_name.

> 
> > 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.

Not really: They didn't interpret the name as a string, but as a raw byte
field of length 0. This is why i made the same change for the POSIX api.
If things are as I believe, the confusing name parameters should of course
disappear.

Peter

>  
> > 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 */
> > >    );
> > >