[Bug libc/5069] env thread safety problem

["zhangxiliang at cn dot fujitsu dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From zhangxiliang at cn dot fujitsu dot com  2007-09-26 02:29 -------
(In reply to comment #2)
> (In reply to comment #1)
> Hi everyone,
> 
> A problem is not solved in changing getenv(). Since __add_to_environ() has 
> called realloc() and realloc() has called getenv() inside, a deadlock may 
> occur.

Hi, the deadlock should not occur here. Because the __libc_rwlock_rdlock
function can check the deadlock problem.

The achieve of __libc_rwlock_rdlock() as follows:
/* Make sure we are not holding the rwlock as a writer.  This is
   a deadlock situation we recognize and report.  */
if (__builtin_expect (rwlock->__data.__writer == THREAD_GETMEM (THREAD_SELF,
tid), 0))
{
     result = EDEADLK;
     break;
}
I think use the rw_lock here can solve the problem.

In your patch, you may only reduce the probability of segment fault. The problem
may be not solved. The reason as follows: 

The achieve of getenv() as follows:
for (ep = __environ; *ep != NULL; ++ep)
{
#if _STRING_ARCH_unaligned
	  uint16_t ep_start = *(uint16_t *) *ep;
#else
	  uint16_t ep_start = (((unsigned char *) *ep)[0]
			       | (((unsigned char *) *ep)[1] << 8));
#endif

	  if (name_start == ep_start && !strncmp (*ep + 2, name, len)
	      && (*ep)[len + 2] == '=')
	    return &(*ep)[len + 3];
}
When getenv() hang a long time after "ep = __environ", the other process calls
the setenv(), unsetenv(), clearenv() to free the old_environ_region buffer. The
ep may be changed to a invalid pointer.

By the way, I think your patch may be more complex. Applying a read_write lock
can slove the problem.
 

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5069

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.