Coyote's Guide to IDL Programming

Bus Error in IDL 6.3 on Mac OSX

QUESTION: I have installed IDL 6.3 onto a Mac OSX (10.4) G4 laptop. In the past (pre 6.3) I have used Terminal.app for the command line - which works great as long as X11 is running. Now I have bumped into a problem in which IDL 6.3 starts and runs from the Terminal.app command line, but when I invoke any graphics commands (PLOT, TV, etc.) IDL exits with a "bus error". Oddly, a HELP, !D, /STRUCT shows that X is the graphics device but HELP, /DEVICE results in the bus error problem. I can run IDL 6.3 just fine from the X11 command line - but that command line is quite limited compared to Terminal.

ANSWER: You can find a complete discussion of this problem in this May 18th, 2006 IDL newgroup thread.

The bottom line is that you must set your DISPLAY environment variable in your Terminal window prior to launching IDL. Here is a short explanation of the problem from Karl Schultz:

All X client programs, including IDL, need to know what X server to connect to. If you open a Terminal on OS X and type:

   xclock

whether an X server is running on your OS X workstation or not, you'll get:

   Error: Can't open display:

The proper approach is to start the X server, and if you intend to start X clients from the Terminal, you need to either set the DISPLAY environment variable to the server's connection address (e.g., :0, or myhost:0), or specify the connection address with a -display keyword parameter (e.g., xclock -display myhost:0).

It turns out that IDL 6.2 and prior somehow connected to the X server running on your OS X desktop without specifying the DISPLAY environment variable. At this exact second, I don't know how this was accomplished. While convenient, one can argue that the behavior is incorrect. IDL should politely fail to create the window and let the user correct the problem. (It is possible that IDL is simply using :0 in the absense of a DISPLAY environment setting and that's why it worked. But IDL's going out on a limb here and making an assumption that you may not want)

OS X provides a rather unusual desktop environment, because the desktop is not controlled by the X server, even when X11 is running. In a more conventional X desktop, any xterm or other client started from a desktop menu inherits the DISPLAY environment variable setting from the server and so DISPLAY is set in the xterm environment. Any clients launched from that xterm will show up on that server.

So, you can do it either way. You just need to be aware of the extra step involved in Terminal to set DISPLAY the way you want it.

The problem was introduced as a side-effect of the new multi-monitor functionality and it happens even if there is only one monitor. I'll look into restoring the 6.2 behavior in the next release, but in the meantime, you really need to set that DISPLAY variable. It is the right thing to do from an X11 point of view.

Ben Tupper has a hard time figuring out exactly how to do this in this .tcshrc file. Eventually, he discovered the proper way to do it was like this:

   setenv DISPLAY ":0"

Feedback

I got this feedback from Edd Edmondson about the advice offered on this page.

Good page explaining the Mac crash issue. However, Karl Schultz makes an important point when he talks about setting DISPLAY to :0. “But IDL's going out on a limb here and making an assumption that you may not want.”

This is an assumption that doesn't often fail, but can do. You can have more than one user logged in at a time on OS X, and each can have their own X server running. The later users to log in don't get :0 as a setting, and if they do what Ben Tupper does they may even end up having their windows appear on the other user's desktop - a difficult problem to debug as IDL doesn't complain and windows just appear not to get made. And if you quit IDL before you switch to the other user you'll never get any indication of where those windows got to.

We had a better, but more complex solution in this IDL Newsgroup article and Nathan Nutter sent me a small fix to that solution for the case in which X11 isn't running.

   if [ -e /tmp/.X11-unix/* ] then X11_FOLDER=/tmp/.X11-unix
   currentUser=`(set \`whoami\`; echo $1)`
   bb=`ls -l $X11_FOLDER | grep $currentUser`
   bbb=${bb/*X/:}
   usedDISPLAY=$bbb.0
   export DISPLAY=$usedDISPLAY fi

This is a bash script, although I'm sure tcsh could be persuaded to do something similar.

Those who use the idlde program exclusively may find it simpler to alias it to Apple's own script for doing such magic and use 'open- x11 /Applications/rsi/idl_6.3/bin/idlde' or something similar.

Update as of OS X 10.5.7

If you try all this and you still don't have any joy, then almost everyone who owns a Mac recommends you install XQuartz instead of the X11 that is shipped by Apple. It is, by all accounts, significantly less buggy than the Apple version. Installing it often solves even the most recalcitrant problems. Note that you have to perform the Mac OS update and then install XQuartz on top of that. Also note you have to do this XQuartz install every time you update the OS, no exceptions.

I have had the following report from someone working with IDL 6.1 on Mac OS X 10.5.7 who tried to follow the instructions above and ran into this problem.

So I downgraded to the same version that my coworker had installed (XQuartz 2.2.3) and then updated, one step at a time, up the most recent version. I don't know what the difference is, but IDL gives me a 'bus error' for any of the XQuartz 2.3.3.* versions. Everything works fine with the 2.3.2.1 version, which is what I have installed now. I don't know if this makes any difference, but I am using ssh from a Windows machine with PuTTY and Xming (can't get cygwin to work on Vista); however, when I went into work for a few minutes today I was able to ssh using another Mac (or a linux box) and use IDL without any problems.

Other people have found the ideas in this IDL Newsgroup article helpful.

Google
 
Web Coyote's Guide to IDL Programming