| View previous topic :: View next topic |
| Author |
Message |
mkcolg
Joined: 30 Jun 2004
Posts: 4996
Location: The Portland Group Inc.
|
 Posted: Wed Jan 16, 2013 4:06 pm Post subject: |
 |
|
| Quote: | | I am suspecting this due to me not deallocating the device matrices before the end of the program, is that correct? |
Probably not. The memory will be freed once your program exits. More likely you have some uninitialised memory. The memory may happen to be zero the first time you run the program, but some other value the next.
| Quote: | | 0: DEALLOCATE: memory at 0000000000000000 not allocated |
This mean that the memory has already been deallocated or was never allocated in the first place.
- Mat |
|
| Back to top |
|
 |
Dolf
Joined: 22 Mar 2012
Posts: 78
|
| Posted: Wed Jan 16, 2013 4:54 pm Post subject: |
|
|
| Quote: | | Probably not. The memory will be freed once your program exits. More likely you have some uninitialised memory. The memory may happen to be zero the first time you run the program, but some other value the next. |
how can overcome this problem??
thanks,
Dolf |
|
| Back to top |
|
|
mkcolg
Joined: 30 Jun 2004
Posts: 4996
Location: The Portland Group Inc.
|
| Posted: Wed Jan 16, 2013 5:48 pm Post subject: |
|
|
Probably the best way is to compile in emulation mode with floating point trapping enabled (-Mcuda=emu -g -Ktrap=fp). If you're correct that it's a divide by zero, this should pin point the place where it occurs. Otherwise, run the same binary in the debugger, PGDBG, and see if you can determine at what point the NANs start occurring. From there back track until you find the cause.
- Mat |
|
| Back to top |
|
|
Dolf
Joined: 22 Mar 2012
Posts: 78
|
| Posted: Wed Jan 16, 2013 8:39 pm Post subject: |
|
|
| Quote: | | Probably the best way is to compile in emulation mode with floating point trapping enabled (-Mcuda=emu -g -Ktrap=fp). If you're correct that it's a divide by zero, this should pin point the place where it occurs. |
I did compile the code in debug mode using the above keys (-Mcuda=emu -g -Ktrap=fp). it takes longer time to calculate the results. in the middle it gave me the error: PGI debug engine
Process 0: signalled FLT_INVALID_OPERATION at 0x4019ca1d, function _fmth_i_dlog, file 418, line 0
which does not make alot of sense to me. I used to pass this point with no errors when compiling without emu mode.
can you please explain? I am running out of ideas now.
Dolf |
|
| Back to top |
|
|
mkcolg
Joined: 30 Jun 2004
Posts: 4996
Location: The Portland Group Inc.
|
| Posted: Thu Jan 17, 2013 10:10 am Post subject: |
|
|
Think of "FLT_INVALID_OPERATION" as a Windows catch all for a non-specific floating point exception. Can you track down which "log" call is throwing this exception?
It may be a acceptable exception (like an underflow) in your code that can be ignored. However, you should look at what value is being passed to log and how the results are being used.
- Mat |
|
| Back to top |
|
|
|
Search
Memberlist
Register
Profile
Log in
