Re:1.5.19: changes have broken Qt3

[Ralf Habacker <ralf dot habacker at freenet dot de>]

-----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 <pthread_mutexattr_init+259>:   mov    (%edi),%eax
0x610b1005 <pthread_mutexattr_init+261>:   cmpl   $0xdf0df049,0x4(%eax)
0x610b100c <pthread_mutexattr_init+268>:   je     0x610b1070
<pthread_mutexattr_init+368>

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  <ralf.habacker@freenet.de>

	* 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/