I have a structure called 'CameraStruct' that has a pointer to it called 'Camera'. I store qword data to VerticalViewAngle. I initialize the data with a 1. I then go to another subroutine that retrieves these numbers. It uses the correct pointer and offsets but OllyDbg shows a NaN FFFF C0000000 00000000 is retrieved instead.

Here is the memory location and data: 00402000 00 00 00 00 00 00 F0 3F

.data?
Camera CameraStruct <>

.code
mov ebx,Camera ;Get the pointer to the camera, it loads 402000

assume ebx:ptr CameraStruct

fld .VerticalViewAngle

Here is the very top of the structure:

CameraStruct struct 8

VerticalViewAngle real8 ?

What am I missing?
Posted on 2003-03-11 11:53:44 by drhowarddrfine
What is the value of EBX in the debugger?

mov ebx, OFFSET Camera ; Get the pointer to the camera, it loads 402000

or

mov ebx, ADDR Camera ; Get the pointer to the camera, it loads 402000
Posted on 2003-03-11 12:02:38 by bitRAKE
ebx is 402000 and I'm using offset. The offset in the code is +8 and the store and load parts of the code both point to that location.
Posted on 2003-03-11 12:12:30 by drhowarddrfine
Strange, I don't have enough information to provide further guidance.
Could you post a small program that exhibits the error?
Posted on 2003-03-11 13:43:29 by bitRAKE
I have to pack to go home and I have jury duty tomorrow. I'll post the code later. Thanks.
Posted on 2003-03-11 15:23:52 by drhowarddrfine
Well, I don't have jury duty tomorrow after all. It was called off.

There's nothing really to add for the code. It's the very beginning of the routines.

The structure is just a bunch of variables declared as real8. The structure is defined as CameraStruct.

In the .data? section I say Camera CameraStruct <> ? Which should create space for it.

The address of the structure is 402000. One of the routines writes data into this location properly:

fst .VerticalViewAngle ;This location is actually 402000+8 and Ollydbg shows this.
;Yes, I know I'm using eax here and ebx later.

This address gets passed to another routine that is trying to read the data.
so I load the address into ebx:

mov ebx,Camera ; from the stack

ebx is definitely loaded with 402000. I can see it in Ollydbg.

then I say assume ebx:ptr CameraStruct so masm knows what we're using it for.

then I say:

fld .VerticalViewAngle

Ollydbg shows the address pointed to is but it loads the Nan mentioned above.
Posted on 2003-03-11 23:35:20 by drhowarddrfine
How about a "finit" at the begining of your program to initialize the FPU.


If not this, try these:

finit
lea ebx, Camera
fld QWORD PTR .CameraStruct.ViewAngle


:alright:
NaN
Posted on 2003-03-12 00:52:27 by NaN
I tried finit but that didn't solve it.
I can't use lea because I want the pointer to Camera to be passed to this routine.
I tried the qword ptr but that didn't solve it.

The biggest problem though is everything looks as it should. ebx contains the right address to the data, it just doesn't load what's there.
Posted on 2003-03-12 07:29:42 by drhowarddrfine
drhowarddrfinedrhoward, could this be an error with OllyDbg - does it happen if you just run the code w/o the debugger?
Posted on 2003-03-12 07:38:58 by bitRAKE
Strange.. I'm making some camera code as well but the FPU loading seems to be working fine for me.
Posted on 2003-03-12 13:49:30 by x86asm
I know how frustrating this stuff is. I was programming my audio engine and while it was running I would stop it in the middle of operation and I would see all FPU tags marked as BAD. Man I was angry. Ya I think there may be a bug in OllyDBG. Because everything I would do in a situation like this has already been suggested. I'm writing 3D camera code as well, but I believe my implementation is much simpler than yours.
Posted on 2003-03-12 13:53:42 by x86asm
Were they marked bad using Ollydbg? Is anyone aware of such bugs in Ollydbg?

I tried using GoBug but it doesn't work with XP (you have to buy that one). I don't remember if debug with windows handles fpu code or not. I haven't used it in years.

This is an engine I'm using for a special effects project I'm finally getting to concentrate on. Not that I don't have a bazillion other things to do.
Posted on 2003-03-12 15:32:31 by drhowarddrfine

Were they marked bad using Ollydbg? Is anyone aware of such bugs in Ollydbg?
I haven't seen such a bug in OllyDbg, but debuggers are real sensive things to write. Just write a test piece that outputs to a message box or something. Load the value into the FPU, operate on it and display the result.
Posted on 2003-03-12 15:51:08 by bitRAKE
Also drhoward I noticed some of the FPU tag words are marked as zero. Which means that before you loaded a float onto the stack, st(7) could have been marked zero and as a result st(0) is marked as bad when u execute "fld". So I think that you should keep the FPU stack clean, it may kill some clk cycles but it ensures safety :)
Posted on 2003-03-12 17:46:47 by x86asm

Also drhoward I noticed some of the FPU tag words are marked as zero. Which means that before you loaded a float onto the stack, st(7) could have been marked zero and as a result st(0) is marked as bad when u execute "fld". So I think that you should keep the FPU stack clean, it may kill some clk cycles but it ensures safety :)


I think I was told by (BitRake?) to use FCOMPP to clean the FPU stack it pops the register stack twice. So only 4 consecutive FCOMPP's and the whole stack is clean.
Posted on 2003-03-12 17:48:32 by x86asm
I downloaded Microsoft's WinDbg. I don't quite know how to use it but it does show the proper value in the st registers (1.0). I zero some of those registers beforehand but I'm heading out the door for dinner so I'll look into your suggestions. For now, though, it looks like a problem with Ollydbg.:(
Posted on 2003-03-12 18:05:06 by drhowarddrfine

I downloaded Microsoft's WinDbg. I don't quite know how to use it but it does show the proper value in the st registers (1.0). I zero some of those registers beforehand but I'm heading out the door for dinner so I'll look into your suggestions. For now, though, it looks like a problem with Ollydbg.:(


Please also look at my suggestion. I had the same problem and keeping the FPU stack clean eliminated that problem for me.
Posted on 2003-03-12 18:18:02 by x86asm
"finit" also clears the stack (with a single instruction).

If Windbg shows the proper value, Ollydbg may be the problem. I only use Windbg.

Raymond
Posted on 2003-03-12 23:17:47 by Raymond
Skip the need for other tools.. if you have the MASM v8, the VKIM debuging macro's has one called "DumpFPU"

include .\masm32\include\debug.inc

includelib .\masm32\lib\debug.lib

finit
DumpFPU "Cleaned the FPU Stack"

fld [ebx].CameraStruct.CameraValue
DumpFPU "Loaded Camera Angle"


And take a look at it. Another thing to do is backwards check. If your trying to unsucessfully load say 1.23 from a memory location. Build a test scenario to see what the memory "should" look like.



.data
test DQ 1.23

.code
lea edx, test
mov eax, [edx]
PrintHex eax, "Lower DWord"
mov eax, [edx+4]
PrintHex eax, "Upper DWord"
finit
DumpFPU "Clean Stack"

fld QWORD PTR [edx]
DumpFPU "Hardcoded correct value"

lea ebx, Camera
mov eax, [ebx].CameraStruct.CameraAngle
PrintHex eax, "Lower DWord - indirect"

add ebx, 4
mov eax, [ebx].CameraStruct.CameraAngle
PrintHex eax, "Upper DWord - indirect"

sub ebx, 4
fld [ebx].CameraStruct.CameraAngle
DumpFPU "Dynamically Loaded Camera Value"


Then look at the output. They should be the same. If not you can trace to the point of information failure. Which my guess would be how EBX recieves its pointer (without seeing the full source ~ and assuming there is no OlyDbg BUG).

Hope it helps
:alright:
NaN
Posted on 2003-03-13 01:48:00 by NaN
Talked to Olly. Quick response. Good guy.:alright:

Apparently I may be mistaking how the stack pointer works. Maybe that's what you, x86asm, were trying to say, the stack pointer is overflowing but I thought it would just wrap around. I don't care if it wraps around but I guess it marks the registers as bad and sets condition codes. I haven't re-read this yet so I don't think I've got it quite right yet.

Anyway, I just wanted to post this so everyone knew there was no bug in OllyDbg.
Posted on 2003-03-13 19:49:26 by drhowarddrfine