Re: bug in NSApplication

[Chris B . Vetter]

On Mon, 15 Jul 2002 12:11:04 -0600
Adam Fedor <address@hidden> wrote:
> > 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.
> Well the reason this was changed is that any (malicious) user could 
> destroy any file they wanted to, simply by doing:
> gdomap -I destroy_this_file

Yes, I followed that thread and I agree, that it is an issue.

> Perhaps we should change it back but only allow the PID file to be 
> written if the program is run by the root user? I hope someone else has 
> an opinion on this as I don't think I'm smart enough to know all the 
> implications.

I guess if gdomap switches to 'nobody' immediately after creating its
PID file, no harm could be done. If a PID file is necessary, for a regular
user, it could be created in $TMP, which _should_ point to $HOME/tmp anyway.

> > 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.
> It should work. Although if you access the sharedApplication object, you 
> would need to set it after sharedApplication was created.

Since it's a Tool, I don't use -sharedApplication ... that's the funny
thing, I don't know where the popup comes from, or why, for that matter.
Oh well, I do, sortof. I put some fprintf() and NSLog() inside the method
that raises the exception and from what I can see, the popup shows up
immediately upon raising the exception.
And as said before, in an Application, the _same_ code works just fine.

> > 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.
> I've had this had this happen on occation, but never enough to be able 
> to isolate the problem. If you can send me a set of instructions that do 
> this repeatedly, I can isolate it.

I wish I could.
Basically all I did was, one by one, openapp the application(s) and click
'Exit', nothing else. I've seen this behaviour on one of my own apps, which
didn't properly "clean up" upon exiting. So it might be some memory issue.

-- 
Chris