Bug with pthreads
Peter Pointner
pr at schenk.isar.de
Wed Feb 23 16:44:42 UTC 2000
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 */
> > > );
> > >
More information about the users
mailing list