Re: bug in NSApplication

[Chris B . Vetter]

On Sun, 14 Jul 2002 21:12:37 -0600
Adam Fedor <address@hidden> wrote:
> BALATON Zoltan wrote:
> > Hello,
> > Adam Fedor wrote:
> >>I've made various half-hearted tries at debugging it. It seems like some
> >>problem with how we allocate or release X resources. That's about all I
> >>can figure out so far.
> > Is it possible that XCloseDisplay is called more than once or with an
> > invalid display handle? FWIW I've got the following stack trace. I've
> > also seen it without the Xkb functions, so it most probably fails
> > somewhere in_XFreeDisplayStructure.
> I think I've fixed this. Please try the latest CVS and see if it works 
> for you also.

Hi,

I've noticed a few problems with last Friday's CVS. After switching to
gcc3.0.4, I basically re-compiled the whole system from scratch, including
libs, like ffcall and libxml2.
gnustep-make picked up the 'new' libobjc and everything went smoothly.


However, upon launching gdomap and gdnc, the former complained that
it wasn't able to connect to port 538. Closer inspection showed that
the creation of /var/run/gdomap.pid happens _after_ switching to user
'nobody' - bad idea, since (at least) on BSD systems, /var/run is only
writable by root. Ok, that's easy enough to fix, I can either move the
creation before the user switch, or chmod /var/run. Though I prefer to
do the former.


The second problem I encountered was by launching any application. As
soon as the backend bundle get's initialized, any application will NSLog
a message, that 'NSWindow initialized' (or created? Not sure). Well, it's
not really a problem, but not really necessary either.


The third was by launching GNUMail - and only GNUMail. It will raise an
exception almost immediately, that 'NXConstantString does not recognize
getCharacter:' ... RFM states in an email to Yen-Ju Chen, that this "is
a sure indicator of a problem with the objc runtime library." - If that's
the case, I wonder why it _only_ happens with GNUMail?!
OTOH, I saw Ludovic's statement that GNUMail is b0rk, as he termed it, on 
channel #GNUstep.


Maybe I'm mistaken (or, more likely, do something wrong) but it seems like
NSSetUncaughtExceptionHandler(foobar) called from a Tool does not really
change the exception handler to foobar().
Whenever I try to raise an exception, say

  [NSException raise: @"Foobar"
              format: @"Foobar occured"]

instead of jumping to foobar() (in which I'm checking [exception name] and
run through a couple of if()'s) I'm presented with a popup window (huh?!)
showing "Foobar" in the upper part, and "Foobar occured" in the lower. I
can imagine what will happen, if I run that Tool without X...
Btw, I used the same code in an Application, and it works just as supposed
to, that is, jumping to foobar(), not showing any popups.


Finally, and more closely to the inital mail, ImageViewer, Gorm and
ProjectCenter will take any WM down upon closing almost every 8 out
of 10 times. I've tested all examples in CVS as well as a couple of
others, like GSPdf or Preferences - those seem to be working fine.

-- 
Chris