[bug #22351] GDNC not starting properly on some systems.

[Riccardo mottola]

Update of bug #22351 (project gnustep):

 Open/Closed: In Test => Closed 


___

Reply to this item at:

  

___
  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.

[Yavor Doganov]

Follow-up Comment #19, bug #22351 (project gnustep):

I tested yesterday's changes to NSMessagePortNameServer.m (as applied on the
stable branch) with Debian's Base 1.14.1 and everything works as expected.

Many thanks for fixing this annoying problem.

___

Reply to this item at:

  

___
  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.

[Richard Frith-Macdonald]

Follow-up Comment #18, bug #22351 (project gnustep):

As expected ... the solaris64bit issue seems to have nothing to do with this
bug report.

___

Reply to this item at:

  

___
  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.

[Sebastian Reitenbach]

Follow-up Comment #17, bug #22351 (project gnustep):

I checked out svn yesterday evening, and recompiled, gdnc is staring up
successfully as before, but still crashing on openbsd sparc64, as described on
the other bug report. 

___

Reply to this item at:

  

___
  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.

[Riccardo mottola]

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:

  

___
  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.

[Gregory John Casamento]

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:

  

___
  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.

[Yavor Doganov]

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:

  

___
  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.

[Richard Frith-Macdonald]

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:

  

___
  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.

[Richard Frith-Macdonald]

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:

  

___
  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.

[Gregory John Casamento]

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:

  

___
  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.

[Richard Frith-Macdonald]

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:

  

___
  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.

[Yavor Doganov]

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:

  

___
  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.

[Richard Frith-Macdonald]

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:

  

___
  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.

[Yavor Doganov]

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:

  

___
  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.

[Richard Frith-Macdonald]

Follow-up Comment #6, bug #22351 (project gnustep):

Is this a duplicate of #21415 ?

I *think* we are talking about two separate isssues, but it's not clear to
me.

The issue in #21415 is that gdnc sometimes crashes (I think this is only on
startup, but  perhaps when a client connects to it?)

The issue here seems to be that clients fail to connect to gdnc ... now is
there really a problem in the client at all, or is this just that the client
fails to connect because gdnc has crashed?

___

Reply to this item at:

  

___
  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.

[Richard Frith-Macdonald]

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:

  

___
  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.

[Sebastian Reitenbach]

Follow-up Comment #4, bug #22351 (project gnustep):

gdnc is working well on OpenBSD i386, cannot remember having seen a problem
there. I've a OpenBSD sparc64 system, there the problem manifests "every
time". Start gdnc, then try starting an application, e.g. GNUmail or
AddressManager, and gdnc segfaults.
Maybe it has sth. to do with 64Bit systems. I think this bug report is a
duplicate of this, still open one: https://savannah.gnu.org/bugs/?21297

however, I could offer a ssh account to the OpenBSD sparc64 box, in case
someone wants to investigate. sebastia[at]l00-bugdead-prods.de





___

Reply to this item at:

  

___
  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.

[Richard Frith-Macdonald]

Follow-up Comment #3, bug #22351 (project gnustep):

I would describe that as a hack to hide a problem (and therefore make it
harder to fix any real bug).
If there is a problem running out of file descriptors, then a fix would be to
use fewer of them, so we can try that instead.
Unfortunately this issue seems to be quite a rare, system-specific thing...
Riccardo let me try to reproduce it on his BSD system for a while, but I
could't get it to occur and it doesn't happen on any of the GNU/Linux systems
I've access to.

___

Reply to this item at:

  

___
  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

Re: [bug #22351] GDNC not starting properly on some systems.

[Gregory John Casamento]

It may be the architecture I'm using x86_64 w/ hyper-threading. 
 
I haven't been able to reproduce reliably on another installation of Linux, but 
it can be reproduced on *BSD machines regularly.

GJC

--
Gregory Casamento -- Principal Consultant - OLC, Inc 
# GNUstep Chief Maintainer

- Original Message 
From: Charles philip Chan <[EMAIL PROTECTED]>
To: bug-gnustep@gnu.org
Cc: Gregory John Casamento <[EMAIL PROTECTED]>
Sent: Sunday, February 17, 2008 7:51:43 PM
Subject: Re: [bug #22351] GDNC not starting properly on some systems.

Gregory John Casamento <[EMAIL PROTECTED]> writes:

> On many systems OpenBSD, NetBSD, and some Linux distros (notably SuSE
> 9.3) GDNC is failing to start properly.

This is really strange that you got that result. I had no problems
starting GDNC on SuSE 9.3 system since it came out (I am on 10.3 now).

Charles


-Inline Attachment Follows-

___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep






___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

Re: [bug #22351] GDNC not starting properly on some systems.

[Charles philip Chan]

Gregory John Casamento <[EMAIL PROTECTED]> writes:

> On many systems OpenBSD, NetBSD, and some Linux distros (notably SuSE
> 9.3) GDNC is failing to start properly.

This is really strange that you got that result. I had no problems
starting GDNC on SuSE 9.3 system since it came out (I am on 10.3 now).

Charles


pgpvdbRWjYeA3.pgp
Description: PGP signature
___
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.

[Gregory John Casamento]

Follow-up Comment #2, bug #22351 (project gnustep):

Richard, please take a look at the code which was changed and give any
feedback you feel necessary.  GC.

___

Reply to this item at:

  

___
  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.

[Gregory John Casamento]

Update of bug #22351 (project gnustep):

  Status: In Progress => Fixed  
 Open/Closed:Open => In Test

___

Follow-up Comment #1:

Research found that this might be linked to file descriptors being exhausted
by the polling in the connect method after starting the gdnc server.

I added a wait of three seconds which seems to address the issue.  GJC

___

Reply to this item at:

  

___
  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.

[Gregory John Casamento]

URL:
  

 Summary: GDNC not starting properly on some systems.
 Project: GNUstep
Submitted by: gcasa
Submitted on: Sunday 02/17/2008 at 19:21
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: In Progress
 Privacy: Public
 Assigned to: gcasa
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

On many systems OpenBSD, NetBSD, and some Linux distros (notably SuSE 9.3)
GDNC is failing to start properly.

Steps to reproduce:
1) make sure all daemons are stopped...
2) start an application using gopen or openapp
Result: the application will time out and give the "unable to contact GDNC
server" error.
Expected: the application should start properly and GDNC should be launched.

This problem has been on these systems for the past couple of years.  GJC




___

Reply to this item at:

  

___
  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