X-Spam-Check-By: sourceware.org
Message-ID: <4474250C.AA4A166@dessent.net>
Date: Wed, 24 May 2006 02:19:08 -0700
From: Brian Dessent <brian AT dessent DOT net>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: 1.5.19: changes have broken Qt3
References: <044e01c67e8f$0abed720$a501a8c0 AT CAM DOT ARTIMI DOT COM> <447350C4 DOT 1080604 AT freenet DOT de> <20060523182326 DOT GB6138 AT trixie DOT casa DOT cgf DOT cx> <4473607C DOT 2070806 AT freenet DOT de> <44741E31 DOT 665A1B7 AT dessent DOT net> <447420D1 DOT 8090909 AT freenet DOT de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Ralf Habacker wrote:

> There is no segfault, but it does not work as expected e.g.
> pthread_mutexattr_init() does not fill the pthread_mutexattr_t struct
> given as parameter.

How does it not work?  The testcase runs fine for me with no assertion
failures, neither from a prompt nor in (CVS) gdb.  Even when I modify it
as follows:

--- pthread_mutexattr_init.c    2006-05-24 02:05:52.523968000 -0700
+++ pthread_mutexattr_init_2.c  2006-05-24 02:11:27.299406200 -0700
@@ -9,6 +9,9 @@ main()
 {
   assert(pthread_mutexattr_init(&mxAttr) == 0);
   assert(pthread_mutexattr_settype(&mxAttr, PTHREAD_MUTEX_ERRORCHECK)
== 0);
+  int t;
+  pthread_mutexattr_gettype(&mxAttr, &t);
+  assert(t == PTHREAD_MUTEX_ERRORCHECK);
   assert(mutex == NULL);
   assert(pthread_mutex_init(&mutex, &mxAttr) == 0);
   assert(mutex != NULL);

...it still runs without failure.

BTW the whole "myfault" thing was devised specifically to kill the
IsBadReadPtr() junk that was used before, so asking for that back is
probably never going to happen.  And with good reason too, because when
you call IsBadReadPtr is does exactly what "myfault" does, it installs a
temporary fault handler, tries to read the memory, and then removes that
temporary fault handler.  Except that if you call IsBadReadPtr a bunch
of times it has to do this setup/teardown every time, instead of just
doing it once for the entire lexical scope of the function, as with
myfault.

And yes, it used to be that gdb was too dumb to recognise that these
faults in IsBadReadPtr were not actual faults, and it would print them
as spurious SIGSEGVs, just as it currently does for "myfault"s.  Then it
was patched to ignore faults in kernel32.dll.  Now that the handler is
in cygwin1.dll, it had to be taught to ignore faults there too, and if
you use a CVS GDB, it does.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/