ALERT FROM PostMaster Express AVAC
=== System Generated Message - DO NOT REPLY TO THIS ! === PostMaster AvAc has processed the mail detailed below and has generated this alert for your reference. Message Details: --- Message ID: [EMAIL PROTECTED] Message From : cygwin-xfree@cygwin.com Message To: spmore [EMAIL PROTECTED] Message Subject : Mail Delivery (failure [EMAIL PROTECTED]) Message Rcvd Date : Sun Dec 11 14:12:11 GMT+05:30 2005 --- PostMaster AvAc removed the following file(s) / attachment(s) as per the organization's attachment control policy: --- File Deleted: message.scr !-- Virus-Free Mail Using PostMaster Express AvAc QuickHeal Engine --! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Mutex init failure trying to run Scribus
René Berber wrote: versions of gdb and also Microsoft's WinDbg, all show the same problem Program received signal SIGSEGV ... in pthread_key_create. I'll look into this tomorrow, I've used gdb under XWindows in HP-UX and Solaris but this is the first time under Cygwin/X, perhaps something is different. You can ignore that. Just type continue and things will work fine. There is probably a way you instruct gdb to automatically ignore this but I don't know what it is off the top of my head. The reason you get that is because of the verifyable_object business where a data structure is checked for a magic number before continuing, but in this case the thing being checked is an uninitialized pointer. However this is handled by design with the efault mechanism which installs a temporary SEH handler that allows the code to specify if something segfaults in the current lexical block, don't bail out but instead do the following, as can be seen in verifyable_object_isvalid(): myfault efault; if (efault.faulted ()) return INVALID_OBJECT; if ((static_ptr1 *object == static_ptr1) || (static_ptr2 *object == static_ptr2) || (static_ptr3 *object == static_ptr3)) return VALID_STATIC_OBJECT; if ((*object)-magic != magic) return INVALID_OBJECT; return VALID_OBJECT; On the other hand, it would be nice to know what is calling pthread_key_create on a null pointer, since that sounds like a buglet, but due to the above it's a benign situation. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Mutex init failure trying to run Scribus
On Sat, Dec 10, 2005 at 09:30:27PM -0600, Yaakov S (Cygwin Ports) wrote: Ren? Berber wrote: I tried using cygwin1.dll version 1.5.18 and it works just like you said. Then I downloaded the latest snapshot, version 20051207, and scribus fails as before (no error messages, the one I used as subject is only a warning, nothing). As this is an apparent regression, if you could track this down in the cygwin1.dll, I'm sure Corinna and cgf would like to know about it on the main list. (I, for one, won't be very happy if my programs stop working when 1.5.19 comes out!) I'm sure that you won't be be but I, for one, won't be very happy when the people who use your programs conclude that any problems they have, whether they are packaging, cockpit, or otherwise, should be discussed here. I'm glad that you are clarifying things on your web site. It would be nice if there was another place where people could get help with your packages so that we could be assured that, when problems turn up here, they are likely to be problems with the cygwin dll or the cygwin distribution rather than standard random end-user complaints about installation or misconceptions. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Mutex init failure trying to run Scribus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yaakov S (Cygwin Ports) wrote: [snip] (I, for one, won't be very happy if my programs stop working when 1.5.19 comes out!) [snip] Running Scribus with the debug enabled cygqt-mt-3.dll the program works fine with no mutex failure message and using the latest Cygwin snapshot. As mentioned in my reply to Brian, under gdb there are many SIGSEGV signals received but continuing results in the same behaviour as above: no problem. So there seems to be no regression, there must be something different btw. the original build environment and my PC. I used the code (build script, patches and original code) downloaded using setup.exe. Problem solved. - -- René Berber -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iEYEARECAAYFAkOcvA4ACgkQL3NNweKTRgw24ACg9uZkQFnVSbmRRfJSw/XHFpVc efUAoKWzYERoA23dgpVPja7EuzmqK/Eb =oJ/5 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Mutex init failure trying to run Scribus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Dessent wrote: [snip] You can ignore that. Just type continue and things will work fine. There is probably a way you instruct gdb to automatically ignore this but I don't know what it is off the top of my head. Thanks! Using continue after 2 of those SIGSEGV the program finally started. Then many more appeared before the splash screen appears (which is the first thing you see while running this program)... every SIGSEGV is received after doing a pthread operation. The reason you get that is because of the verifyable_object business where a data structure is checked for a magic number before continuing, but in this case the thing being checked is an uninitialized pointer. However this is handled by design with the efault mechanism which installs a temporary SEH handler that allows the code to specify if something segfaults in the current lexical block, don't bail out but instead do the following, as can be seen in verifyable_object_isvalid(): myfault efault; if (efault.faulted ()) return INVALID_OBJECT; if ((static_ptr1 *object == static_ptr1) || (static_ptr2 *object == static_ptr2) || (static_ptr3 *object == static_ptr3)) return VALID_STATIC_OBJECT; if ((*object)-magic != magic) return INVALID_OBJECT; return VALID_OBJECT; On the other hand, it would be nice to know what is calling pthread_key_create on a null pointer, since that sounds like a buglet, but due to the above it's a benign situation. It seems to be the qt3 dll use of threads, the first looks like this: (gdb) where #0 0x610ad5e8 in pthread_key_create (key=0x100e25f0, destructor=0) at /netrel/src/cygwin-snapshot-20051207-1/winsup/cygwin/thread.cc:129 #1 0x6108d16f in _sigfe () at /netrel/src/cygwin-snapshot-20051207-1/winsup/cygwin/cygserver.h:82 #2 0x59432d52 in ?? () #3 0x100e25f8 in ?? () #4 0x0001 in ?? () #5 0x100e25f8 in ?? () #6 0x0022edb8 in ?? () #7 0x610ae367 in pthread::once (once_control=0x100e25f8, init_routine=0x22ee08) at /netrel/src/cygwin-snapshot-20051207-1/winsup/cygwin/thread.cc:2027 #8 0x610ae367 in pthread::once (once_control=0x100e25f8, init_routine=0x714b6e30 cygqt-mt-3!_ZN11QMotifStyle18qt_static_propertyEP7QObjectiiP8QVariant+18128) at /netrel/src/cygwin-snapshot-20051207-1/winsup/cygwin/thread.cc:2027 #9 0x6108d16f in _sigfe () at /netrel/src/cygwin-snapshot-20051207-1/winsup/cygwin/cygserver.h:82 #10 0x0022ede8 in ?? () #11 0x714b6ef5 in cygqt-mt-3!_ZN11QMotifStyle18qt_static_propertyEP7QObjectiiP8QVariant () from /bin/cygqt-mt-3.dll #12 0x714b6ef5 in cygqt-mt-3!_ZN11QMotifStyle18qt_static_propertyEP7QObjectiiP8QVariant () from /bin/cygqt-mt-3.dll #13 0x714b4fe3 in cygqt-mt-3!_ZN11QMotifStyle18qt_static_propertyEP7QObjectiiP8Q Variant () from /bin/cygqt-mt-3.dll #14 0x711a990f in cygqt-mt-3!_ZN18QMetaObjectCleanUpC1EPKcPFP11QMetaObjectvE () from /bin/cygqt-mt-3.dll #15 0x714b27c2 in cygqt-mt-3!_ZN11QMotifStyle18qt_static_propertyEP7QObjectiiP8QVariant () from /bin/cygqt-mt-3.dll #16 0x61010263 in per_module::run_ctors (this=0x0) at /netrel/src/cygwin-snapshot-20051207-1/winsup/cygwin/dll_init.cc:55 #17 0x0001 in ?? () #18 0x610102b1 in dll::init (this=0x6101067c) at /netrel/src/cygwin-snapshot-20051207-1/winsup/cygwin/dll_init.cc:81 #19 0x716f0008 in ?? () #20 0x in ?? () from Then there are several that look like: Program received signal SIGSEGV, Segmentation fault. pthread_mutex::init (mutex=0x100e463c, attr=0x22edec, initializer=0x0) at /netrel/src/cygwin-snapshot-20051207-1/winsup/cygwin/thread.cc:129 ... Program received signal SIGSEGV, Segmentation fault. pthread_mutex::init (mutex=0x100fe44c, attr=0x22ea0c, initializer=0x0) at /netrel/src/cygwin-snapshot-20051207-1/winsup/cygwin/thread.cc:129 ... Program received signal SIGSEGV, Segmentation fault. 0x610ad5e8 in pthread_key_create (key=0x715e4690, destructor=0) at /netrel/src/cygwin-snapshot-20051207-1/winsup/cygwin/thread.cc:129 ... Program received signal SIGSEGV, Segmentation fault. 0x610ac5e5 in pthread_mutexattr_init (attr=0x22e0cc) at /netrel/src/cygwin-snapshot-20051207-1/winsup/cygwin/thread.cc:129 ... and so on. On a second run it doesn't start the same, it goes into: Program received signal SIGSEGV, Segmentation fault. pthread_mutex::init (mutex=0x100e463c, attr=0x22edec, initializer=0x0) at /netrel/src/cygwin-snapshot-20051207-1/winsup/cygwin/thread.cc:129 - From what you said, the initializer=0x0 is what casuses the SIGSEGV. I'll take a closer look at the qt3 library. Thanks! - -- René Berber -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iEYEARECAAYFAkOcrC0ACgkQL3NNweKTRgxEFwCfX5p52egyM6XmRy0Iz0ovCRj3 mY4AoPXZLVpJwcxY8d27KWWDjd3H131K =37XX -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports:
Re: Mutex init failure trying to run Scribus
René Berber wrote: - From what you said, the initializer=0x0 is what casuses the SIGSEGV. I'm not sure if that's what's causing it, because it doesn't try to dereference that. I think what's happening is that this: /* The opengroup docs don't define if we should check this or not, but creation is relatively rare. */ if (pthread_key::is_good_object (key)) return EBUSY; at the beginning of pthread_key_create causes the fault. I.e. it's checking if the key happens to already be valid before creating it, which is going to fail most of the time, for good reason. So, not a bug. In a normal program it doesn't matter because of the efault stuff, but when debugging it results in all those spurious SIGSEGVs. If I understand this right you can safely comment out the above check without affecting much of anything, just to shut up gdb. Or you can try handle SIGSEGV nostop, noprint, pass. But then you'd miss a legitimate SEGV -- I don't know if that's what you're trying to track down or not. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Mutex init failure trying to run Scribus
Brian Dessent wrote: [snip] If I understand this right you can safely comment out the above check without affecting much of anything, just to shut up gdb. Or you can try handle SIGSEGV nostop, noprint, pass. But then you'd miss a legitimate SEGV -- I don't know if that's what you're trying to track down or not. No, the original problem was not a SIGSEGV, it was that the program just exited silently after showing the splash screen and doing some initalizations. This only happened with post 1.5.18 Cygwin dll, but I built the qt library (with debug enabled) and the problem disapeared. I'm rebuilding the library now w/o debugging. Thanks again. -- René Berber -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
