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?
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?
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
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
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.
Strange, I don't have enough information to provide further guidance.
Could you post a small program that exhibits the error?
Could you post a small program that exhibits the error?
I have to pack to go home and I have jury duty tomorrow. I'll post the code later. Thanks.
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.
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.
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
If not this, try these:
finit
lea ebx, Camera
fld QWORD PTR .CameraStruct.ViewAngle
:alright:
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.
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.
drhowarddrfinedrhoward, could this be an error with OllyDbg - does it happen if you just run the code w/o the debugger?
Strange.. I'm making some camera code as well but the FPU loading seems to be working fine for me.
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.
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.
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.
Were they marked bad using Ollydbg? Is anyone aware of such bugs in Ollydbg?
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 :)
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.
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.:(
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.
"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
If Windbg shows the proper value, Ollydbg may be the problem. I only use Windbg.
Raymond
Skip the need for other tools.. if you have the MASM v8, the VKIM debuging macro's has one called "DumpFPU"
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.
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
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
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.
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.