View on GitHub

IRAF Community Distribution

IRAF maintained by the community

Home | Installation | Packages | X11IRAF | PyRAF | Forum

ximtool on macs: runaway ism_wcspix proccesses…

Philip Massey wrote on Apr 30, 2006

Hi, Mike---

Deidre complained that her G5 machine at work seemed a little "unresponsive", and I checked with "top", and found there were 6 (!) ism_wcspix processes
fighting to see who could get the most CPU. I have seen this in the past under
OSX: if I kill an ximtool, and then do a "top", MOST (but not ALL) of the time
there is usually a "ism_wcspix" process left over that is eating up all of the CPU.
Once I "kill -9" it things are fine again.

I think we corresponded about this once, but I can't remember if there was a solution to this problem other than to make sure to check. I see the same problem with m G4 PowerBook as with my dual G5 machine at work, and the
behavior is the same under Tiger as it was with whatever big scary cat preceeded Tiger.

Any advice? Thanks!

---phil

Let me add that despite this annoyance, using ximtool on the Mac is GREAT. We've set up X11 so it is 8 bits, and so that doesn't affect any of the rest of the display; I personally don't see how people can use ds9 if they are doing lots of intercomparisons of different frames.

Mike Fitzpatrick wrote on Apr 30, 2006

Hi Phil,

We've exchanged mail on this for years across several platforms but I tried again todays and I still can't reproduce it. You did say "when I kill ximtool" which confirms my suspicions this is a zombie process problem. Is there some reason 'Quit' doesn't work? Knowing this is a problem, can't you just kill the ism the same time you kill ximtool? Have you got a recipe I can use to reproduce this?

BTW, on Mac/Intel the 8-bit X11 is broken completely -- any X task started in 8-bit mode appears to have the text garbled. It is actually there but not all of the pixels making up a character are drawn so the 'garbled' is just dropouts. This is apparently an apple X server bug, still trying to find a fix for it. This is similar to the problems reported with xgterm a while back, for some reason though I never saw that one on my machine.

Cheers,
-Mike

Philip Massey wrote on Apr 30, 2006

Hi, Mike---

OK, I think I figured out what we are doing differently.

If I exit ximtool by pressing the "Quit" button, in fact I do not seem to get
these runaway ism processess. I just tried it ten times and it didn't happen
once.

However, what I usually do is "quit" ximtool the way I quit all of windows on
my Mac: I clck on the little red button the upper left corner of the window.
That certainly gets rid of ximtool. But, it does not get rid of the ism process.
Instead, the latter becomes a monster eating up all of the cpu. This seems to
happen for me at least 90% of the time, and maybe 100%.

Does that help, and can you now reproduce it?

Now that I know this, at least, I have a way of avoiding it...

---phil

Philip Massey wrote on Apr 30, 2006

Let me add that I was doubtless exiting ximtool in much the same way on
Solaris.

Philip Massey wrote on Apr 30, 2006

I just checked with Deidre, and she confirms she's been "exiting" ximtool in the same graceless manner as I have. It turns out NEITHER of us had ever noticed that there even is a "Quit" button until today.

How come everyone else doesn't have this problem? It must be a generational thing. :oops:

Mike Fitzpatrick wrote on Apr 30, 2006

Aaaahhh, well, that only took a decade to sort out. That *is* something I can work with and fix for the next release. The X11IRAF stuff will likely get some attention this month and updates posted as part of the beta. Use the 'Quit' for now and beware that XGterm may have the same "behavioral problem".

Cheers,
-Mike

Last post on Apr 30, 2006