[bug #22351] GDNC not starting properly on some systems.
Follow-up Comment #5, bug #22351 (project gnustep): Certainly not a generic 64bit problem ... because it works fine on my development machine (debian intel 64bit). However, a sparc specific 64bit issue would not surprise me (since sparc is picky about word alignments), and there is always the possibility of a problem with the ffcall library on a specific platform (or with gnustep's use of it). ___ Reply to this item at: http://savannah.gnu.org/bugs/?22351 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #22351] GDNC not starting properly on some systems.
Follow-up Comment #7, bug #22351 (project gnustep): This problem happens quite often in Debian as of Base 0.14 (which has the --auto option by default), with many applications; users have reported such problems on i386, powerpc and amd64. The solution in comment #1 does not help, unfortunately. I've been using a modified GNUstep Base on all my machines for some time and I can't reproduce the problem with the attached patch. This is not a clean solution either, since it generally slows down app startup time. Either way, debugging this obscure problem is really hard. (file #15064) ___ Additional Item Attachment: File name: clean-tmpdir.diff Size:1 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?22351 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #22351] GDNC not starting properly on some systems.
Follow-up Comment #8, bug #22351 (project gnustep): Looks like a problem with the NSMessagePortNameServer code failing to protect some changes with locks. Deleting the nameserver database and all the ports (as in the patch) is not really a solution since it effectively breaks everything else using distributed objects for private host-local connections (the default for inter-app communications). ___ Reply to this item at: http://savannah.gnu.org/bugs/?22351 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #22351] GDNC not starting properly on some systems.
Follow-up Comment #9, bug #22351 (project gnustep): But this happens at a time when gdnc is either not started or is non-functional, so it is safe to assume that no such connections exist. Isn't it so? I may be totally wrong, I don't understand the code very well. Here's how I've been able to trigger this bug, although not reliably (as I said I cannot reproduce with my patch, whether right or wrong -- and I certainly don't claim it's right): 1. Kill all daemons as suggested in the original submission. 2. Start an app (Ink, Preferences) that would lead to gdnc launching. 3. Kill the app, so that the nameserver database remains (quiting the app in a normal way should usually clean the database). 4. Kill gdnc. 5. Start the app again. (Repeat steps 2-4 if the bug doesn't show yet.) ___ Reply to this item at: http://savannah.gnu.org/bugs/?22351 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #22351] GDNC not starting properly on some systems.
Follow-up Comment #11, bug #22351 (project gnustep): If there is a problem running out of file descriptors, then a fix would be to use fewer of them I agree that what I did is not a perfect solution. The root of the problem is that the polling in that method for a connection is causing the process to block because the file descriptors allowed for that process are quickly used up. This happens because, at least on linux, the send and receive ports are created by making special files in /tmp. Riccardo also verified that it's the file descriptors on his NetBSD box by using the code prior to my change and setting the number of allowed file descriptors to the maximum. Giving the server time to come up and register itself means that we'll do less polling and, thus, use fewer file descriptors. Nevertheless, it does address the issue on a number of platforms where this problem was occurring. I suggest we leave the present hack in place until a proper fix is found. GC. ___ Reply to this item at: http://savannah.gnu.org/bugs/?22351 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #22351] GDNC not starting properly on some systems.
Follow-up Comment #10, bug #22351 (project gnustep): But this happens at a time when gdnc is either not started or is non-functional, so it is safe to assume that no such connections exist. Isn't it so? No it's not safe to make any such assumption since programs could register their own names (or try to contact other processes) before they access gdnc. Also, if gdnc has died, there may be a whole lot of other processes whose ports and names would be wiped out at the point when you tried to start gdnc. ___ Reply to this item at: http://savannah.gnu.org/bugs/?22351 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #22351] GDNC not starting properly on some systems.
Follow-up Comment #12, bug #22351 (project gnustep): If there is a problem running out of file descriptors, then a fix would be to use fewer of them Sure ... but it turns out that the problem was nothing to do with running out of file descriptors. The root of the problem is that the polling in that method for a connection is causing the process to block because the file descriptors allowed for that process are quickly used up. This happens because, at least on linux, the send and receive ports are created by making special files in /tmp. But ensuring that those descriptors are closed immediately (ie so that the process cannot possibly run out of descriptors) did not cure the problem, and of course the use of a large number of descriptors in one client cannot explain why other clients could then not contact the server ... so the descriptors were a red herring. Giving the server time to come up and register itself means that we'll do less polling Yes ... good to poll less frequently ... I put a 0.05 of a second delay between each poll. Enough to cut down significantly on cpu usage without causing a discernable delay in application startup. and, thus, use fewer file descriptors. Each time we poll we we re-use the same file descriptors, so frequency of polling doesn't affect that. Hopefully the changes to NSPortMessageNameServer.m to implement locking will have cureed this issue by preventing two processes from interfering with each other (your long sleep on startup would have reduced, but not eliminated, the chance of the two processes both trying to access the port name at the same time). ___ Reply to this item at: http://savannah.gnu.org/bugs/?22351 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #22351] GDNC not starting properly on some systems.
Follow-up Comment #14, bug #22351 (project gnustep): No it's not safe to make any such assumption... Ah, thanks. So my approach is entirely unacceptable, as you said. Hopefully the changes to NSPortMessageNameServer.m to implement locking... I'll test extensively tomorrow at work, they should apply cleanly and work with 0.14 as well. ___ Reply to this item at: http://savannah.gnu.org/bugs/?22351 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #22351] GDNC not starting properly on some systems.
Follow-up Comment #13, bug #22351 (project gnustep): I saw a comment from Riccardo saying that the NSMessagePortNameServer change seems to have fixed the problem ... but since it's an intermittent problem, it would be good to get the fix confirmed for other systems and/or by other people. NB. I don't expect that this is the same problem as the segmentation fault in 64bit sparc systems, so I would not be surprised if this fails to cure bug #21415 ___ Reply to this item at: http://savannah.gnu.org/bugs/?22351 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #22351] GDNC not starting properly on some systems.
Follow-up Comment #15, bug #22351 (project gnustep): Richard, I tried your fix and it works properly on my machine. I think this is definitely a better fix than the previous one. Thanks, GJC ___ Reply to this item at: http://savannah.gnu.org/bugs/?22351 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #22351] GDNC not starting properly on some systems.
Follow-up Comment #16, bug #22351 (project gnustep): As I commented on IRC, the current solution seems to have improved my NetBSD system, although I did only a quick test, if it is intermittent, only further testing will verify it. Surely it improved things, since before on NetBSD it always locked up. I verified the problem on netbsd/x86, netbsd/ppc32, netbsd/sparc32. So it is surely not a 64bit-only problem I will check ppc32 and Sparc32 asap. Gregory had it on SuSE x86 instead, so it was not a NetBSD specific thing. On FreeBSD/x86 it did work before and it continues to work. ___ Reply to this item at: http://savannah.gnu.org/bugs/?22351 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #22358] Recent patch causes PopUp/PullDown menus to appear on the side
URL: http://savannah.gnu.org/bugs/?22358 Summary: Recent patch causes PopUp/PullDown menus to appear on the side Project: GNUstep Submitted by: gcasa Submitted on: Monday 02/18/2008 at 20:05 Category: Gorm Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: Please see the attached to see what I am referring to. I spoke about this patch with Fred and with Matt. I'm submitting the bug here so the fix can be tracked. It does this in test mode as well which means that it will display like this until it is fixed if people use Gorm to create their guis. G. ___ File Attachments: --- Date: Monday 02/18/2008 at 20:05 Name: side_open_nspopup.jpg Size: 282kB By: gcasa Shows the NSPopUpButton opening on the side. http://savannah.gnu.org/bugs/download.php?file_id=15073 ___ Reply to this item at: http://savannah.gnu.org/bugs/?22358 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #22358] Recent patch causes PopUp/PullDown menus to appear on the side
Update of bug #22358 (project gnustep): Status:None = Fixed Assigned to:None = gcasa Open/Closed:Open = Closed ___ Follow-up Comment #1: Used helper method. Thanks guys. Great stuff. :) ___ Reply to this item at: http://savannah.gnu.org/bugs/?22358 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
