Re: Bug#426637: Patch to build with FLAC 1.2 and recent GNUstep

[Yavor Doganov]

clone 426637 -1 -2 -3
reassign -1 libgnustep-base1.14
retitle -1 libgnustep-base1.14: NSDistributedNotificationCenter often does not 
establish connection with the freshly started gdnc
severity -1 important
tags -1 + patch
reassign -2 gnustep-base-runtime
retitle -2 gnustep-base-runtime: The gdomap daemon is never started; the init 
script checks for presence of GNUstep.sh and exits
severity -2 normal
reassign -3 gnustep-base
retitle -3 Please reintroduce the package with detached debugging symbols
severity -3 wishlist
thanks

[CCing our local GUG, someone might have the time and will to dive
into this. ]

At Tue, 06 Nov 2007 01:06:13 +0200,
Явор Доганов wrote:
> Gürkan Sengün wrote:
> > 
> > 2007-11-05 09:36:02.865 Cynthiune[8224] Failed to load Gorm
> > 2007-11-05 09:36:02.865 Cynthiune[8224] Could not load Gorm file: 
> > /usr/lib/GNUstep/Applications/Cynthiune.app/Resources/Cynthiune.gorm
> > 2007-11-05 09:36:02.888 Cynthiune[8224] Cannot load the main model file 
> > 'Cynthiune'
> 
> It seems like some obscure issue with gdnc, but it is a separate,
> unrelated bug.

Right, actually this is an old problem.  I found several reports in
the GNUstep mailing lists, all of them virtually the same.  There's
also a recent bug reported for Adun (upstream).  In one of these
reports, Gregory John Cassamento says:

,---- http://article.gmane.org/gmane.comp.lib.gnustep.user/1804 ----
| Sounds like it, you should probably start this in your .xinitrc, which
| is what I do.  Sometimes the daemons start on their own, but sometimes
| they don't.
| 
| This is a convenience feature anyway..  Try starting it by hand and
| see if that helps.
`----

Quite correct, but this issue is going to bite users more than ever
now.  As of GNUstep Base 1.14, gdnc (when not running and started by
NSDistributedNotificationCenter) is by default launched with `--auto',
and it automatically shuts itself when nothing is using it.

I can reproduce this relevantly easy with Ink, Cynthiune, Preferences
but not with apps that do not use Gorm, such as LuserNET or GNUMail.
To see what's going on:

1. Kill the gdnc process(es).
2. Start the app 
   $ Ink --GNU-Debug=NSDistributedNotificationCenter \
         --GNU-Debug=NSMessagePort --GNU-Debug=NSConnection

I tried to find out why the connection fails.  The logical thing to do
was to increase the time limit while retrying the connection.  This
didn't work with a value upto 90 seconds:

2007-11-10 13:24:27.026 Cynthiune[12134] portForName: GDNCServer host: 
2007-11-10 13:24:27.027 Cynthiune[12134] _livePort: 
/tmp/GNUstepSecure1000/NSMessagePort/names/R0ROQ1NlcnZlcg==
2007-11-10 13:24:27.028 Cynthiune[12134] not live, couldn't open file (No such 
file or directory)
2007-11-10 13:24:27.029 Cynthiune[12134] not a live port
(repeated multiple times in the loop)
(NSException is raised)

It seems that for some odd reason, the file in
/tmp/GNUstepSecure1000/NSMessagePort/ports/ is not always created
while the connection is retried in the loop.  Once a speaking port is
created, there is nothing to prevent the connection so it always
succeeds.

While stepping in GDB I can never reproduce the problem, which makes
me think there is some kind of a race.
The attached very lamish patch is only a workaround that doesn't solve
the real problem.  It adds another loop (doing nothing) for 1 sec before
attempting the connection and loops while checking for the port
availability (most probably this is useless, since that's what the
`rootProxyForConnectionWithRegisteredName:' method does).  It also
increases the time limit to 10 seconds -- on my machine (i386, Pentium
233 MHz) 5 seconds are not always sufficient.  Anyway, I can't
reproduce the bug with the patch applied.

> > http://gnu.ethz.ch/debian/preferences/
> 
> This just fixes the build; I'll look more carefully tomorrow why it
> doesn't run as expected.

Gürkan, sorry for misleading you.  Preferences runs just fine.  (I
had an installation at $HOME, which caused "Bad application class
'nil'" abort and that confused me initially).

Hubert, what do you think about this obscure problem?  Can you
reproduce it?  Should it be filed upstream?  I'm sure more
investigation is necessary -- I'll take a deeper look after the
GNUstep transition, but any suggestions/comments are welcome.  (My
apologies if this excessive cloning annoyed you.)

Happy GNUstepping!

NSDistributedNotificationCenter_connect.patch
Description: Binary data