This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


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

RE: pthreads works, sorta


> -----Original Message-----
> From: Christopher Faylor [mailto:cgf@redhat.com]
> 
> 
> On Wed, Jun 27, 2001 at 02:31:28AM -0400, Christopher Faylor wrote:
> >On Wed, Jun 27, 2001 at 02:51:13PM +0800, Dmitry Timoshkov wrote:
> >>"Robert Collins" <robert.collins@itdomain.com.au> wrote:
> >>
> >>[skipped]
> >>
> >>> What does all this mean? We need to catch invalid memroy 
> access, and
> >>> ValidQuery was supplied by Chris as a tool to do that.
> >>
> >>In a multithreaded environment VirtualQuery, IsBad* and 
> similar approaches
> >>are wrong. It can't be guaranteed that after a successful 
> test that memory
> >>will be still accessable.
> >
> >They are not necessarily wrong if they are controlled by 
> appropriate mutexes.
> >The file handling code should be protected this way.   I 
> don't know about
> >the thread code, though.
> 
> Actually, this is wrong.  I was assuming that access to an 
> object X would
> only be by well-behaved manipulators of object X.  It's 
> possible for a rogue
> thread to do something odd with a wild pointer and still 
> screw up memory.
> 
> So SEH is the only safe way to handle this.  However, I don't 
> think that SEH
> will actually work in the Cygwin DLL.

Thats the crux of the problem. Can "kernel code" use SEH. I know that
SEH in gcc uses pthreads, pthread_keys, and one other function group
from memory. You could get into a nasty recursive exception situation
there!. Or we teach GCC to do SEH with native threads, and then compile
just cygwin1.dll with such a gcc?

Rogue threads are always an issue: the user can deliberately trash
in-cygwin memory because we're in the same process. If we can get this
daemon off the ground, some code, such as mutex creation can actually
move to another "trusted" process where the rogue possibilities are
reduced.

Anyway, as I've said, the objects I'm verifying are created and
destroyed exclusively by "kernel" code, so while a userland rogue thread
could run rampant through the address space free()ing everything, it's
guaranteed to crash elsewhere anyway. I can mutex the access to each
type of variable (except mutexs which would need win32Mutex's :]), or
even each structure (and I do for condition variables to ensure
fairness), but POSIX doesn't protect against progammer mistakes of that
nature (ie destroying a cond variable from thread b as thread begins a
pthread_condwait()). The behaviour is undefined for such cases, and as
I've said ... the _whole_ intent of the memory access check is to handle
garbage variable passing, not concurrency.

I.e. if the user has
pthread_t *threads;
threads = malloc (user-thread-count * sizeof(pthread_t));
for (n = 0; n< user-thread-count; n++)
    assert (pthread_create(&threads[n]));

the c library may return memory that is NULL, or memory that is (say)
ababababab. That's what I'm catching!

Rob

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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