X-Spam-Check-By: sourceware.org
Message-ID: <4473607C.2070806@freenet.de>
Date: Tue, 23 May 2006 21:20:28 +0200
From: Ralf Habacker <ralf DOT habacker AT freenet DOT de>
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>
In-Reply-To: <20060523182326.GB6138@trixie.casa.cgf.cx>
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: <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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher Faylor schrieb:
> On Tue, May 23, 2006 at 08:13:24PM +0200, Ralf Habacker wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Dave Korn schrieb:
>>> On 23 May 2006 18:10, Ralf Habacker wrote:
>>>
>>>   Oh no, not this old saw again!
>>>
>>>> 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
>>> [ snip many more ].
>>>
>>>> I identified the problem to the function pthread_mutexattr_init address
>>>> 0x610b1005 in which a null pointer (%eax below) causes this seg fault
>>>   Yes, but it's wrapped in an exception handler.  That's why you get to see an
>>> strace error message, rather than having the process exit.  Names like
>>> "cygwin_except_handler" and "_cygtls::handle_exceptions" should have given you
>>> some clues about this
>> Hmmh, I have learned to fix obviously problems instead let it handle by
>> an exception handler, which has several disadvantages.
>>
>> 1. It costs additional runtime. In the mentioned designer i count 1653
>> internal exceptions, which are caused by the null pointer issue.
>>
>> 2. 70% of my strace output (1000 lines) are polluted by this internal
>> exceptions messages, which could be avoided by changing only on lines of
>> code. Do you think that this is the effort worth ?
>>
>> Are there more problems with this simple patch ?
> 
> The obvious problem is that you have provided an analysis of the common
> code path.  If the standard code path does not usually involve a NULL
> pointer then your patch introduces a statistically unneeded test, i.e.,
> in your test case there are NNN internal exceptions but you haven't
> stated that your test case is the standard way that these functions
> would be used.  

Okay, here is one of the test cases. Can anyone confirm, that this is a
standard way ?

#include <assert.h>
#include <pthread.h>

pthread_mutex_t mutex = NULL;
pthread_mutexattr_t mxAttr;

int
main()
{
  assert(pthread_mutexattr_init(&mxAttr) == 0);
  assert(pthread_mutexattr_settype(&mxAttr, PTHREAD_MUTEX_ERRORCHECK) == 0);
  assert(mutex == NULL);
  assert(pthread_mutex_init(&mutex, &mxAttr) == 0);
  assert(mutex != NULL);
  assert(pthread_mutex_lock(&mutex) == 0);
  assert(pthread_mutex_unlock(&mutex) == 0);
  assert(pthread_mutex_destroy(&mutex) == 0);
  assert(mutex == NULL);
  return 0;
}

Running this testcase results in an internal exception in
pthread_mutexattr_init()

Program received signal SIGSEGV, Segmentation fault.
0x610b1005 in pthread_mutexattr_init (attr=0x404040) at
../../../../src/winsup/cygwin/thread.cc:129
129       if ((*object)->magic != magic)
1: x/i $eip  0x610b1005 <pthread_mutexattr_init+261>:   cmpl
$0xdf0df049,0x4(%eax)

the variable object is located in eax, which is zero.

(gdb) p $eax
$1 = 0

There are two threads

(gdb) info thread
  2 thread 5772.0x1abc  0x7c91eb94 in ntdll!LdrAccessResource () from
ntdll.dll
* 1 thread 5772.0xc50  0x610b1005 in pthread_mutexattr_init
(attr=0x404040) at ../../../../src/winsup/cygwin/thread.cc:129

and the backtrace say that pthread_mutexattr_init() is called by _sigfe

(gdb) bt
#0  0x610b1005 in pthread_mutexattr_init (attr=0x404040) at
../../../../src/winsup/cygwin/thread.cc:129
#1  0x61090d68 in _sigfe () at ../../../../src/winsup/cygwin/cygserver.h:82
#2  0x00401050 in mainCRTStartup ()
(gdb)

but this backtrace save only that this functions seems to called from
the signal thread.


> If the standard code path involves non-NULL pointers
> then adding your test would mean a net slowdown.

> Also, since the current code is supposed to deal with the problem
> without your patch, your patch can't be considered as anything other
> than a band-aid until the reason for the problem is actually understood.
> 
your right, hope the above mentioned stuff help for this.

Ralf



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEc2B8oHh+5t8EXncRAlVrAJoDPcvJb/ynI6T+m4jtiUwxTlweQwCgoD6k
nEtFHGFWiE3j0SaMBUgCVRE=
=gRS1
-----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/