This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
__fwalk mutex problem
- From: Hans-Erik Floryd <hans-erik dot floryd at rt-labs dot com>
- To: newlib at sources dot redhat dot com
- Date: Fri, 27 Mar 2009 14:22:34 +0100
- Subject: __fwalk mutex problem
Hello,
The __fwalk and __fwalk_reent functions lock the file mutex before
calling the walk function. They unlock the mutex when the function returns.
for (g = &ptr->__sglue; g != NULL; g = g->_next)
for (fp = g->_iobs, n = g->_niobs; --n >= 0; fp++)
if (fp->_flags != 0)
{
_flockfile (fp);
if (fp->_flags != 0 && fp->_file != -1)
ret |= (*function) (fp);
_funlockfile (fp);
}
When you call __fwalk(ptr, fclose), as _cleanup_r does, there is a
problem because fclose will release the mutex. When the function returns
__fwalk will call _funlockfile on a file that is closed.
With our mutex implementation that gives an error, because a released
mutex is flagged as invalid.
Is it necessary for __fwalk to lock the file before calling the walk
function? When __fwalk is called with fclose and fflush it seems
unnecessary, because both of those functions lock the mutex internally.
In __srefill_r there is a call to _fwalk with lflush as the walk
function. It calls fflush after inspecting fp->_flags, is the lock
needed in this case? If so lflush could be modified to lock the file
internally.
(There is also __fp_lock_all and __fp_unlock_all to consider. I am not
sure how these are used though, couldn't find a reference anywhere).
Cheers,
Hans-Erik Floryd