Mail Archives: cygwin/2006/05/24/08:21:13
-----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/
- Raw text -