| Re: Runtime error woes [message #55059] |
Mon, 30 July 2007 10:39 |
Mort Canty
Messages: 134
Registered: March 2003
|
Senior Member |
|
|
Jean H. schrieb:
>> I ran an intensive memory check on the desktop and got no errors. Can
>> anyone tell me what might cause such behavior?
>>
>> Thanks
>>
>> Mort
>
> Hi Mort,
>
> Just in case....
> I found that some memory testing programs does not work that well...
> some running under windows will find no error while memTest86, ran at
> the startup of the computer, would find millions of errors... so if you
> haven't used this (free) one, give it a try!
>
> Jean
>
Thanks Jean. I just downloaded it and will try it out.
Mort
|
|
|
|
| Re: Runtime error woes [message #55060 is a reply to message #55059] |
Mon, 30 July 2007 09:29  |
Jean H.
Messages: 472
Registered: July 2006
|
Senior Member |
|
|
> I ran an intensive memory check on the desktop and got no errors. Can
> anyone tell me what might cause such behavior?
>
> Thanks
>
> Mort
Hi Mort,
Just in case....
I found that some memory testing programs does not work that well...
some running under windows will find no error while memTest86, ran at
the startup of the computer, would find millions of errors... so if you
haven't used this (free) one, give it a try!
Jean
|
|
|
|
| Re: Runtime error woes [message #55063 is a reply to message #55060] |
Mon, 30 July 2007 05:54 |
Mort Canty
Messages: 134
Registered: March 2003
|
Senior Member |
|
|
kuyper schrieb:
>
> Is the underlying hardware the same? If a different kind of chip is
> handling the floating point math on your desktop than is handling it
> on your laptop, that could be the source of the differences. If could
> as minor as a tiny difference in the accuracy with which certain
> operations are peformed, with that tiny difference being magnified
> into a error condition by poorly written code - or it could be an
> outright error in the FP implementation on one of the chips.
>
That sounds plausible. Desktop is an Acer model with Pentium 4, laptop
is an Asus with Centrino Duo. No idea if they handle floating point
math differently.
> It's much easier to diagnose such problems, when you know which
> particular values the variables have at the time the arithmetic error
> message is generated.
>
I'll try your suggestion to dump the variable values. Thanks for your help.
Mort
|
|
|
|
| Re: Runtime error woes [message #55064 is a reply to message #55063] |
Mon, 30 July 2007 04:17 |
James Kuyper
Messages: 425
Registered: March 2000
|
Senior Member |
|
|
mort canty wrote:
> I mentioned this one before, but I'm really hung up on it, so I'll try
> again:
>
> Running a rather long program on my desktop PC under Windows XP, IDL 6.3
> with !EXCEPT=2 I get the following messages:
>
> Program caused arithmetic error: Floating illegal operand
> Detected at FFN::COST 160 D:\Idl\projects\supervised\ffn__define.pro
> Program caused arithmetic error: Floating illegal operand
> Detected at FFN::COST 162 D:\Idl\projects\supervised\ffn__define.pro
> Program caused arithmetic error: Floating illegal operand
> Detected at FFN::COST 164 D:\Idl\projects\supervised\ffn__define.pro
> Program caused arithmetic error: Floating illegal operand
> Detected at FFNKAL::TRAIN 112
> D:\Idl\projects\supervised\ffnkal__define.pro
> Program caused arithmetic error: Floating illegal operand
> ...
> ...
>
> This goes on for a while and then the program crashes. I cannot for the
> life of me find any errors in the code at the lines indicated that
> could cause this. In fact, I don't believe there are any, because what's
The key quesion is what precisely happens on the lines from which
those messages are generated? I'd recommend inserting debugging print
statements just before line 160, printing out the value of every
variable whose value could affect the behaviour of that line of code.
Depending upon the nature of your program, that might involve an awful
lot of output, so you might need to dump it to a file. It's a brute
force method, but I've found it useful when more efficient methods
don't work.
> driving me nuts is this: On my laptop, exact same program, exact same
> OS, exact same IDL, still with !EXCEPT=2, I get no runtime error
> messages whatsoever and the program completes successfully.
Is the underlying hardware the same? If a different kind of chip is
handling the floating point math on your desktop than is handling it
on your laptop, that could be the source of the differences. If could
as minor as a tiny difference in the accuracy with which certain
operations are peformed, with that tiny difference being magnified
into a error condition by poorly written code - or it could be an
outright error in the FP implementation on one of the chips.
It's much easier to diagnose such problems, when you know which
particular values the variables have at the time the arithmetic error
message is generated.
|
|
|
|
| Re: Runtime error woes [message #55067 is a reply to message #55064] |
Mon, 30 July 2007 01:44 |
Mort Canty
Messages: 134
Registered: March 2003
|
Senior Member |
|
|
Craig Markwardt schrieb:
> mort canty <m.canty@fz-juelich.de> writes:
>
>> I mentioned this one before, but I'm really hung up on it, so I'll try
>> again:
>>
>> Running a rather long program on my desktop PC under Windows XP, IDL
>> 6.3 with !EXCEPT=2 I get the following messages:
>>
>> Program caused arithmetic error: Floating illegal operand
>> Detected at FFN::COST 160 D:\Idl\projects\supervised\ffn__define.pro
>> Program caused arithmetic error: Floating illegal operand
>> Detected at FFN::COST 162 D:\Idl\projects\supervised\ffn__define.pro
>> Program caused arithmetic error: Floating illegal operand
>> Detected at FFN::COST 164 D:\Idl\projects\supervised\ffn__define.pro
>> Program caused arithmetic error: Floating illegal operand
>> Detected at FFNKAL::TRAIN 112
>> D:\Idl\projects\supervised\ffnkal__define.pro
>> Program caused arithmetic error: Floating illegal operand
>> ...
>> ...
>
> It sounds like it's time to put some HELP debugging statements around
> line 160 of ffn__define.pro
>
>> This goes on for a while and then the program crashes. I cannot for
>> the life of me find any errors in the code at the lines indicated
>> that could cause this. In fact, I don't believe there are any, because
>> what's driving me nuts is this: On my laptop, exact same program,
>> exact same OS, exact same IDL, still with !EXCEPT=2, I get no runtime
>> error messages whatsoever and the program completes successfully.
>
> The obvious question, since you didn't mention it: is the data set
> exactly the same?
>
> Craig
Hi Craig. Quite right of you to ask, but yes, the data sets are
identical on both systems. I've been setting breakpoints strategically
in the code so that the program will interrupt when an array has a
non-finite element, a la IF MIN(FINITE(VAR) EQ 0 ... I find that, on the
desktop computer, NaNs are appearing which then propagate through the
calculation and bring it to its knees. On the laptop the breakpoints are
not triggered and everything is fine. Can this maybe be caused by an
incorrect use of pointers, which happens to be innocuous in one memory
configuration and disasterous in the other? Or does IDL's heap
inmplementation exclude such things?
Mort
|
|
|
|
| Re: Runtime error woes [message #55068 is a reply to message #55067] |
Mon, 30 July 2007 01:06 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
mort canty <m.canty@fz-juelich.de> writes:
> I mentioned this one before, but I'm really hung up on it, so I'll try
> again:
>
> Running a rather long program on my desktop PC under Windows XP, IDL
> 6.3 with !EXCEPT=2 I get the following messages:
>
> Program caused arithmetic error: Floating illegal operand
> Detected at FFN::COST 160 D:\Idl\projects\supervised\ffn__define.pro
> Program caused arithmetic error: Floating illegal operand
> Detected at FFN::COST 162 D:\Idl\projects\supervised\ffn__define.pro
> Program caused arithmetic error: Floating illegal operand
> Detected at FFN::COST 164 D:\Idl\projects\supervised\ffn__define.pro
> Program caused arithmetic error: Floating illegal operand
> Detected at FFNKAL::TRAIN 112
> D:\Idl\projects\supervised\ffnkal__define.pro
> Program caused arithmetic error: Floating illegal operand
> ...
> ...
It sounds like it's time to put some HELP debugging statements around
line 160 of ffn__define.pro
> This goes on for a while and then the program crashes. I cannot for
> the life of me find any errors in the code at the lines indicated
> that could cause this. In fact, I don't believe there are any, because
> what's driving me nuts is this: On my laptop, exact same program,
> exact same OS, exact same IDL, still with !EXCEPT=2, I get no runtime
> error messages whatsoever and the program completes successfully.
The obvious question, since you didn't mention it: is the data set
exactly the same?
Craig
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
