Carlos O'Donell wrote:
> Once we have a backtrace, either via a core dump, or attached gdb,
> then we can talk about the likely cause.
See the bug log -- there are lots of them, but none is really useful.
GNUstep Base uses NSLock extensively to protect critical parts of
code, so there's something going very very wrong at the low level.
The only thing that comes to my mind is the way pthread internals are
hidden by using opaque types of the same size. This was done to avoid
exposing internal (for gnustep-base) pthread implementation details
(like ivars), which might change from release to release and from one
pthread implementation to another, causing undesirable API/ABI breaks.
Do you find anything disturbing in this approach, in particular:
--- Headers/Additions/GNUstepBase/GSConfig.h.in (revision 28611)
+++ Headers/Additions/GNUstepBase/GSConfig.h.in (revision 28613)
@@ -203,5 +203,18 @@
#define GSNativeChar char
#endif
+/*
+ * Types used to avoid exposing pthread header in NSLock.h
+ * NB. These types should *never* be used except to provide enough space
+ * in a class layout for the type of data actually used by the pthread
+ * implementation of the current platform.
+ */
+typedef struct {
+ uint8_t dum...@gs_sizeof_cond_t@];
+} gs_cond_t;
+typedef struct {
+ uint8_t dum...@gs_sizeof_mutex_t@];
+} gs_mutex_t;
+
@GS_SIZEOF_COND_T@ and @GS_SIZEOF_MUTEX_T@ should be both 48 on hppa.
(Mehdi/Dann, can you double check that by grepping GSConfig.h?)
Apparently this trick works on all platforms (including hppa on Lenny,
where I've run complex programs in my desire to reproduce).
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
