X-Spam-Check-By: sourceware.org Message-ID: <447341F0.5050105@freenet.de> Date: Tue, 23 May 2006 19:10:08 +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 Content-Type: text/plain; charset=ISO-8859-15 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 Hi all, > It would appear that changes to the cygwin1.dll since 1.5.18-1 (and > before the 20051207 snapshot) have broken Qt3. The relevant threads > until now: It looks that this problem is not limited to qt3 because the following simple test applications taken from the pthread-win32 packages ftp://sources.redhat.com/pub/pthreads-win32/pthreads-snap-2005-03-08.tar.gz results into a seg fault. C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\tests>strace mutex1b | grep C0000005 strace: error creating process mutex1b, (error 2) C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\tests>strace mutex1n | grep C0000005 - --- Process 4872, exception C0000005 at 610B1005 155 78759 [main] mutex1n 4872 _cygtls::handle_exceptions: In cygwin_except_handler exc 0xC0000005 at 0x610B1005 sp 0x22CC00 C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\tests>strace mutex1r | grep C0000005 - --- Process 4960, exception C0000005 at 610B1005 153 40208 [main] mutex1r 4960 _cygtls::handle_exceptions: In cygwin_except_handler exc 0xC0000005 at 0x610B1005 sp 0x22CC00 C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\tests>strace mutex2 | grep C0000005 C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\tests>strace mutex6 | grep C0000005 Assertion failed: (pthread_mutex_lock(&mutex) == 0), file mutex6.c, line 59 C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\tests>strace mutex6n | grep C0000005 - --- Process 4820, exception C0000005 at 610B1005 174 17751 [main] mutex6n 4820 _cygtls::handle_exceptions: In cygwin_except_handler exc 0xC0000005 at 0x610B1005 sp 0x22CBF0 C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\tests>strace mutex6r | grep C0000005 - --- Process 5676, exception C0000005 at 610B1005 182 12533 [main] mutex6r 5676 _cygtls::handle_exceptions: In cygwin_except_handler exc 0xC0000005 at 0x610B1005 sp 0x22CBF0 C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\tests>strace mutex6s | grep C0000005 Assertion failed: (pthread_mutex_lock(&mutex) == 0), file mutex6s.c, line 59 C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\tests>strace mutex7r | grep C0000005 - --- Process 6240, exception C0000005 at 610B1005 174 28939 [main] mutex7r 6240 _cygtls::handle_exceptions: In cygwin_except_handler exc 0xC0000005 at 0x610B1005 sp 0x22CBF0 I identified the problem to the function pthread_mutexattr_init address 0x610b1005 in which a null pointer (%eax below) causes this seg faults 0x610b1003 : mov (%edi),%eax 0x610b1005 : cmpl $0xdf0df049,0x4(%eax) 0x610b100c : je 0x610b1070 The relating source code is in thread.cc inline function verifyable_object_isvalid(): ... if ((*object)->magic != magic) return INVALID_OBJECT; The problem is that if *object is zero the access to the magic element fails. The following patch catch this zero pointer, although I'm not sure if this zero pointer indicates a major fault conditions in the threading stuff Changelog: 2006-05-23 Ralf Habacker * thread.cc (verifyable_object_isvalid): catch zero pointer. Index: thread.cc =================================================================== RCS file: /cvs/src/src/winsup/cygwin/thread.cc,v retrieving revision 1.198 diff -u -b -B -r1.198 thread.cc - --- thread.cc 22 Mar 2006 20:38:26 -0000 1.198 +++ thread.cc 23 May 2006 13:16:57 -0000 @@ -118,6 +118,9 @@ { verifyable_object **object = (verifyable_object **) objectptr; + if (*object == NULL) + return INVALID_OBJECT; + myfault efault; if (efault.faulted ()) return INVALID_OBJECT; After some more investigation I found that there are additional cases where seg faults happens because of object pointer not being null and not be valid. This needs more research. BTW: Using the pthread test applications makes it much easier to check the threading api. For example there is an unhandled case in semaphore::_timedwait where abstime=NULL results into seg fault. If this would be my project I would add such unit test cases as far as possible. Because pthread-win32 is also hosted on sources.redhat.com it may be possible to relicense the test application to cygwin easier as other external sources. If wished, I can help adding some of these test applications. Regards Ralf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEc0HwoHh+5t8EXncRAkXvAJ93oYvQOcPWc0jvLpoFj4lBFUDVxACcCdAc HXNcHvvAF+is8L//ADQMGi0= =wQG1 -----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/