Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Subject: RE: pthreads works, sorta
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 27 Jun 2001 17:38:16 +1000
Message-ID: <EA18B9FA0FE4194AA2B4CDB91F73C0EF7A10@itdomain002.itdomain.net.au>
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: pthreads works, sorta
Thread-Index: AcD+2VVw4vJAKZIvSI+TDHQf3uSatAAABL2w
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id DAA06072

> -----Original Message-----
> From: Christopher Faylor [mailto:cgf AT redhat DOT 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 DOT collins AT itdomain DOT com DOT 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/