This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports 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: Calls to getpid() in clone'd child return parent's pid.


On 9/14/06, Daniel Jacobowitz <drow@false.org> wrote:
I've got no idea any more :-)  But not quite - I distinctly remember
some CLONE_VM handling.

It seems to be:


If CLONE_THREAD was set, skip touching the thread's PID/TID
If CLONE_VM was set, write -1 into the PID/TID
If neither CLONE_THREAD or CLONE_VM was set, then call
__NR_getpid and write that result into PID/TID.

If someone more knowledgable could respond that would rock.
My RESET_PID patch fixes tst-getpid1/2 and tst-align2, but
causes tst-cond16 and tst-cond17 to fail with:

pthread_mutex_lock.c:82: __pthread_mutex_lock: Assertion
`mutex->__data.__owner == 0' failed.

I it is sensitive to PID/TID because __owner is set to TID. The call
to do_clone, and subsequently ARCH_CLONE, has CLONE_VM set, but not
CLONE_THREAD. Therefore I am worried that writing "-1" into PID/TID is
incorrect.

Cheers,
Carlos.


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