This is the mail archive of the
mailing list for the Cygwin project.
Re: 1.5.19: changes have broken Qt3
-----BEGIN PGP SIGNED MESSAGE-----
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!
>>>> 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 ?
pthread_mutex_t mutex = NULL;
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);
Running this testcase results in an internal exception in
Program received signal SIGSEGV, Segmentation fault.
0x610b1005 in pthread_mutexattr_init (attr=0x404040) at
129 if ((*object)->magic != magic)
1: x/i $eip 0x610b1005 <pthread_mutexattr_init+261>: cmpl
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
* 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
#0 0x610b1005 in pthread_mutexattr_init (attr=0x404040) at
#1 0x61090d68 in _sigfe () at ../../../../src/winsup/cygwin/cygserver.h:82
#2 0x00401050 in mainCRTStartup ()
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html