http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14333 <pre> On Tuesday, June 18, 2013 04:47 CEST, Adam Fedor &lt;fedor&lt; at &gt;gnu.org&gt; wrote: I haven't looked into the logs, but I remember that problem from someone else. Newer libxml2 has changed a bit. So, installing gnustep-base 1.24.0 was failing, but trying installing gnustep-base 1.24.4, which definitely should contain a fix about that, worked like a charm. cheers, Sebastian _______________________________________________ Bug-gnustep mailing list Bug-gnustep&lt; at &gt;gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep </pre> Sebastian Reitenbach 2013-06-18T04:30:52 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14332 <pre>Actually, the real error occurs compiling base: GSXML.m: In Funktion »-[GSXMLNode description]«: GSXML.m:987:38: Fehler: Dereferenzierung eines Zeigers auf unvollständigen Typen GSXML.m:987:60: Fehler: Dereferenzierung eines Zeigers auf unvollständigen Typen or, Error: dereferencing pointer to incomplete type (from Google translate) so it seems there is something wrong with a libxml2 header, but I have no idea what. Do you have the libxml2-dev package installed? On Jun 17, 2013, at 8:33 AM, Matthias Uden &lt;matthias.uden&lt; at &gt;googlemail.com&gt; wrote: </pre> Adam Fedor 2013-06-18T02:47:04 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14331 <pre>Hi, I cannot install GNUStep on my Ubuntu 13.04 32bit machine properly. As suggested by the installation script, please find the logs attached. Unfortunately, they are in German (due to my system's default locale). Basically, the last "fatal" error is that the script cannot find AppKit/AppKitExceptions.h I started the installation script with root rights (sudo) and met all prerequisites. Any kind of help on this is appreciated! Thanks a lot in advance and best regards, Matthias Uden _______________________________________________ Bug-gnustep mailing list Bug-gnustep&lt; at &gt;gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep </pre> Matthias Uden 2013-06-17T14:33:22 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14330 <pre>Update of bug #39083 (project gnustep): Status: None =&gt; Fixed Open/Closed: Open =&gt; Closed _______________________________________________________ Follow-up Comment #1: Thanks ... I added that change in trunk _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?39083&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Richard Frith-Macdonald 2013-05-31T09:38:22 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14329 <pre>Update of bug #39082 (project gnustep): Status: None =&gt; Fixed Open/Closed: Open =&gt; Closed _______________________________________________________ Follow-up Comment #1: Thanks.... I added that in trunk. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?39082&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Richard Frith-Macdonald 2013-05-31T09:36:43 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14328 <pre>Update of bug #39078 (project gnustep): Status: None =&gt; Invalid Open/Closed: Open =&gt; Closed _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?39078&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Richard Frith-Macdonald 2013-05-31T09:34:41 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14327 <pre>Update of bug #39126 (project gnustep): Status: None =&gt; Fixed Open/Closed: Open =&gt; Closed _______________________________________________________ Follow-up Comment #1: Thanks ... this was intermittently failing for me because of a race condition. When the second thread locked the mutex before the first thread, and held it locked, the first thread could not lock the mutex and could not even enter the timed wait for the condition. The fix for this was to add a timeout on the initial lock ... so that the -lockWhenCondition:beforeDate: method can return NO in the case where another thread is holding the mutex. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?39126&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Richard Frith-Macdonald 2013-05-31T09:34:01 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14326 <pre>Update of bug #39088 (project gnustep): Status: Need Info =&gt; Fixed _______________________________________________________ Follow-up Comment #5: last patch applied to svn rev 36684. thanks _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?39088&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Sebastian Reitenbach 2013-05-31T08:35:18 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14325 <pre>Update of bug #39092 (project gnustep): Status: Need Info =&gt; Fixed _______________________________________________________ Follow-up Comment #8: applied the patch in svn 36684. thanks. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?39092&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Sebastian Reitenbach 2013-05-31T08:32:07 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14324 <pre>URL: &lt;http://savannah.gnu.org/bugs/?39126&gt; Summary: NSConditionLock -lockWhenCondition:beforeDate: bug Project: GNUstep Submitted by: cpulsford Submitted on: Thu 30 May 2013 07:18:49 PM GMT Category: Base/Foundation Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any _______________________________________________________ Details: I'm running gnustep-base v1.24.4 with gcc v4.7.2 on debian wheezy and an intel celeron processor. I have attached a program that waits on a lock condition for 5 seconds. The condition is set appropriately on a separate thread 10 seconds later, so the -lockWhenCondition:beforeDate: call should fail after 5 seconds. Here is the output when run in Xcode: 2013-05-30 15:00:55.889 test[28892:707] Attempting lock... 2013-05-30 15:01:0</pre> Cameron Pulsford 2013-05-30T19:18:50 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14323 <pre>URL: &lt;http://savannah.gnu.org/bugs/?39125&gt; Summary: Thread deadlock due to combination of libobjc and NSUserDefaults Project: GNUstep Submitted by: msilvax28 Submitted on: Thu 30 May 2013 06:51:50 PM GMT Category: Backend Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any _______________________________________________________ Details: I'm running gnustep-based v1.24.4 w/ gcc v4.7.2 using gcc's libobjc runtime. See the stack trace below. It appears that libobjc4 has some internal lock which it keeps when it calls an objects +initialize method. If that initialize method calls an object like NSUserDefault that has its own lock and another thread does the oppose (calls NSUserDefault that then invokes libobjc4) a thread deadlock can occur. Not sure if this </pre> Michael Silva 2013-05-30T18:51:51 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14322 <pre>It looks like you don't have any X11 development environment setup. I'm not sure exactly how to do that on RedHat - you might have to ask in a RedHat mailing list. You'll basically need to install the X11 development packages (libx11-dev, xorg-dev, libxt-dev, etc). On May 30, 2013, at 3:56 AM, Яковлев Кирилл Игоревич wrote: _______________________________________________ Bug-gnustep mailing list Bug-gnustep&lt; at &gt;gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep </pre> Adam Fedor 2013-05-30T18:36:07 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14321 <pre> _______________________________________________ Bug-gnustep mailing list Bug-gnustep&lt; at &gt;gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep </pre> Яковлев Кирилл Игоревич 2013-05-30T09:56:47 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14320 <pre>Follow-up Comment #7, bug #39092 (project gnustep): Yes it does; that's been my workaround since discovering this problem. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?39092&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Graham Lee 2013-05-30T09:59:51 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14319 <pre>Update of bug #39092 (project gnustep): Status: None =&gt; Need Info Assigned to: None =&gt; buzzdee _______________________________________________________ Follow-up Comment #6: Problem was obviously introduced by me. Attached patch changes the lock into a recursive lock, but I don't know if this is the best idea, waiting on feedback from David. Let me know if that works for you so far. Sebastian (file #28209) _______________________________________________________ Additional Item Attachment: File name: fix-NSLocking-gsweb.diff Size:2 KB _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?39092&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Sebastian Reitenbach 2013-05-30T09:34:15 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14318 <pre>Follow-up Comment #4, bug #39088 (project gnustep): I, and the original author of that code, were relying on the fact that -[GSWMultiKeyDictionary allValues] _does_ in fact return a mutable array although its signature says it returns an array. I think you're correct though and your patch is better: client code that wants the array to be mutable should arrange that itself rather than relying on an implementation detail in the dictionary class. Cheers, Graham. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?39088&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Graham Lee 2013-05-30T09:13:30 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14317 <pre>Update of bug #39088 (project gnustep): Status: None =&gt; Need Info Assigned to: None =&gt; buzzdee _______________________________________________________ Follow-up Comment #3: Hi Graham, i applied all chunks of the patch, but one, where I think its wrong. In the last hunk in your patch to -GSWeb/GSWMultiKeyDictionary.m, you cast from a superclass to a subclass, which I think its not safe. AFAIK, casting is only fiddling with pointers, but its not really changing the type of class that you are casting. So if someone now calls a method implemented in NSMutableArray, it will probably fail miserably. Only when you are sure, nothing in the code will call methods from the subclass, then it might be safe to cast from superclass to subclass. But in the code I see some lines below in -nextObject, calling -removeLastObject on the casted class, and I guess that would fail then. I think casting is only safe the othe</pre> Sebastian Reitenbach 2013-05-30T08:34:06 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14316 <pre>Follow-up Comment #5, bug #39092 (project gnustep): I's on my list of things to look at in the next couple of days, just didn't got around it today. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?39092&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Sebastian Reitenbach 2013-05-29T20:58:29 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14315 <pre>Update of bug #39087 (project gnustep): Status: Ready For Test =&gt; Fixed _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?39087&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Sebastian Reitenbach 2013-05-29T20:57:08 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14314 <pre>Follow-up Comment #4, bug #39092 (project gnustep): this lock was a recursive lock until fairly recently, hopefully sebastian chimes in. https://github.com/gnustep/gnustep-gsweb/commit/3c4e7d11d74ab218118fe0995363c1a93db52b1a#GSWeb/GSWApplication.m _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?39092&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> matt rice 2013-05-29T20:31:37 http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14313 <pre>Follow-up Comment #3, bug #39092 (project gnustep): Forgive me talking to myself, but I've made some progress on this. I wrote my own &lt;NSLocking&gt; class that both checks the pthread_mutex errors and stores the call stack at the point where it gets locked. If it gets deadlocked, it prints both the callstack where it was originally locked and the one where it deadlocked. So we now have this: 2013-05-29 19:40:59.228 EmptyApp[14545:3a07] Error locking GLLock&lt;0x7f8372012120&gt;: 11 2013-05-29 19:40:59.234 EmptyApp[14545:3a07] Was already locked here: ( 0 WebObjects 0x000000010b818c54 -[GLLock lockBeforeDate:] + 148 1 WebObjects 0x000000010b849f58 loggedLockBeforeDateFromFunctionInFileInLine + 88 2 WebObjects 0x000000010b819dc1 -[WOApplication lockRequestHandling] + 113 3 WebObjects 0x000000010b86387d -[GSWActionRequestHandler handleRequest:] + 141 4 WebObjects 0x000000010b81d2</pre> Graham Lee 2013-05-29T18:49:47 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.gnustep.bugs