X-Spam-Check-By: sourceware.org Message-ID: <44744F28.905@freenet.de> Date: Wed, 24 May 2006 14:18:48 +0200 From: Ralf Habacker User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) 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> <4474250C DOT AA4A166 AT dessent DOT net> In-Reply-To: <4474250C.AA4A166@dessent.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Dessent schrieb: > 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. Thanks for this info to understand the new exception handling in cygwin. I was bitten last year by some thread relating problems while porting qt3 to cygwin and had investigated some time to understand this stuff, which has changed much in the meantime. > 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. > You said that the testcase runs, yes, but do you have tried to debug the cygwin dll with this exception handling. Please start the above mentioned testcase in gdb and enter b main r b pthread_mutexattr::pthread_mutexattr() c This breakpoint is never reached (at least in released gdb) and makes it hard to debug cygwin's threading stuff, probably impossible in this area. This means to be able to debug the cygwin dll in this area I have to recompile a special cygwin version with something like below mentioned.: /* FIXME: write and test process shared mutex's. */ extern "C" int pthread_mutexattr_init (pthread_mutexattr_t *attr) old: if (pthread_mutexattr::is_good_object (attr)) return EBUSY; new: if (attr && pthread_mutexattr::is_good_object (attr)) return EBUSY; BTW: This is not to hurt anyone or to bring in miscredit anyones work. We all try our best to make cygwin as good as possible. It is only that in this area things could be done better :-) Regards Ralf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEdE8ooHh+5t8EXncRAhnRAKCfbhfNKawy70+t18zk56M3WHzuLACeJR1C 2WLX0BBt5N7efXQWuav0tNk= =xZn9 -----END PGP SIGNATURE----- -- 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/