| Re: G4-related problem [message #36110 is a reply to message #36021] |
Fri, 15 August 2003 10:50   |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
"Rudi Sch�fer" <rudi.schaefer@physik.uni-marburg.de> wrote in message
news:bh8393$2as$1@surz18.uni-marburg.de...
> Hi.
>
> I recently discovered a very nasty problem on my G4 (2*867, Mac OS X
> 10.2.6) running IDL 5.6.
>
> The following code should not produce any output, if everything works.
> Unfortunately, this is not the case on my G4, where the variable
> assignment "data1=data0" produces messy data in a randomly fashion. So
> it works most of the time, but once in a while, the data in "data1" will
> be corrupted. Typically, there are some zeros showing up in the array
> and some other garbage.
>
> Here is the code in question:
>
> data0=fltarr(10000)+1.
> for ii=0L, 200000 do begin & $
> data1=data0 & $
> if min(where(data1 eq 0)) gt 0 then begin & $
> print, ii & ii=200001L & endif & $
> endfor
>
>
>
> This problem did not show up on other machines I have tested (Compaq
> Alpha, a Windows PC or my iMac G3 running the same OS and IDL versions).
>
> So this can either be a G4-specific bug in IDL 5.6, a G4-specific bug in
> Mac OS X 10.2.6, or a hardware problem on my G4.
Aside from the Altivec code, there is no G4-specific code in IDL. Since the
Altivec is not used for simple copy operations and you disabled it, that
can't be the problem. (But good thinking on disabling it)
> Since I do not have a second G4 available, I would like to ask anyone
> with a G4 to test the code snippet given above. You can simply paste the
> code to the command line in IDL.
> PS: What I already tested:
> - setting TPOOL_NTHREADS=1 and VECTOR_ENABLE=0
> - using different RAM
> - replacing the RAM modules
> - testing the RAM with the hardware test CD
I've spent a bunch of time on this and I think I can help a little here.
- The problem seems to only occur on OS X 10.2. I don't know if the story
changes depending on the version of 10.2 (e.g., 10.2.3). The problem does
not seem to occur on 10.1 and the developer's preview of 10.3. This last it
em is good news.
- I've only seen or heard the problem reported on G4.
- The flavor of the X11 server involved does not matter. The IDL program
needs to be connected to *any* X server to demonstrate the problem. That
is, the issue is all on the client side.
Given those things, the problem is on OS X 10.2 G4's while IDL has an X
connection open.
On some systems (OS X is one), IDL uses a 1-second interval timer proc that
runs whenever there is an X connection. Its job is to keep your graphics
windows reasonably up to date while IDL is performing some long operation,
between interpreter instructions. Disabling this timer operation keeps the
problem from occuring, but at the (minor?) expense of unresponsive windows
during these operations.
So, possible solutions are:
1) Use 10.1 or wait for 10.3.
2) Issue (the undocumented) DEVICE, /NOTIMER to turn off the timer proc.
You'll have to judge if this is ok for your app or not.
3) Make sure your program does not do any graphics. Note that if you have
some DEVICE command in your startup file to configure your windows, this
still makes a connection, even if you don't open any graphic or UI windows.
If you aren't sure if your machine suffers from the problem, I'd suggest
running the program above.
Hope this helps,
Karl
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
