Hi

I have a pretty nasty problem:
if i define a specific variable as part of UNINITIALISED data section of PE it behaves strange and causes nasty problems. Note that working at a very big program (HE game) i defined a large number of variables and i noticed this only twice over time, which is a very small number. First time was a variable that was used as a pointer to a memory zone dinamically allocated and the program just crashed when i used the pointer; second (now) it's just a counter that gets erased for no reason.
Both times the problem was passed by by defining the variables as INITIALISED data.

If anybody has any ideas, please share them with me. Me speculations are:
- not aligned memory
- the PE loader is doing something wrong


Thanks

Eugen
Posted on 2002-07-24 17:48:59 by Eugen
if I remember correctly tasm had a kind of bug that forced you to have something in the initialised data section without it the unitialised wouldn't function :/

I remember people talking in #win32asm about something similar (or this) with tasm not long ago, I'll see if I can find it in my logs.
Posted on 2002-07-24 18:06:37 by Hiroshimator
Thanks

I am waiting to see what you find

Eugen
Posted on 2002-07-24 18:14:33 by Eugen

if I remember correctly tasm had a kind of bug that forced you to have something in the initialised data section without it the unitialised wouldn't function :/

true. if you don't have any initialised data it won't even let you call any api functions.
Posted on 2002-07-24 18:33:09 by Tola
This is not the case here, we have a lot of initialised data in our program
Posted on 2002-07-25 03:33:45 by Eugen
since you state that you have data in both sections I can't help.
I can't find the problem but the solution was to place data (anything) in initialised

sorry :/
Posted on 2002-07-25 08:46:14 by Hiroshimator
It sounds like one of your buffers is overwriting data. Changing a variable from the .data? to the .data section should relocate the memory address and prevent that variable from being overwritten, no?
Posted on 2002-07-25 12:50:05 by grv575
This could be a logical explanation, but i tested this and apparently its not it. I had 2 variables allocated one after another, one gets erased and the other dosent. Before and after the variable erased i added one large buffer to prevent it from being erased and still i get the same behavior. So apparently its not it :(
Posted on 2002-07-26 04:22:38 by Eugen
Well, I hope you're not making the very common mistake of doing this:

; bad code, DataArea not changed

mov eax,offset DataArea ; (or a call to HeapAlloc)
mov pPointer,eax
; ...
mov [pPointer],ebx ; changes pPointer
mov [pPointer].field2,ebx ; changes data following pPointer
The x86 does not do data indirection via memory. To do it properly, the pointer value must be put in a register.

; correct code, changes DataArea and data after DataArea

mov eax,offset DataArea ; (or a call to HeapAlloc)
mov pPointer,eax
; ...
mov ecx,pPointer ; put pointer in register
mov dword ptr [ecx],ebx
mov (struct1 ptr [ecx]).field2,ebx
Posted on 2002-07-26 18:59:37 by tenkey
No, i'm not using structures of any kind in this case. One example is very simple; i just set a value in a variable and make a loop until a counter reaches this value. The value just somehow is set with '0' and loop exits instantly.
Thx anyway
Posted on 2002-07-26 20:04:10 by Eugen
With some mixtures of compilers/assemblers and linkers, there have been
trouble with 'common' data (also known as .data? or BSS). Weird problems
can happen if you have multiple global-scope variables with the same name.
This can happen due to header file misconfiguration (declaring the same var
twice even though you didn't think you did this). I'm not saying this is the
problem, but I had similar trouble when I had multiple non-static globals
with the same name in GCC compiled sourcecode. With the version of the
GNU linker I had, I didn't even get a warning :(. Just a guess, but a failed
guess is better than nothing?
Posted on 2002-07-26 20:53:24 by f0dder
Eugen, please post an example for us if you can. It is important to narrow the problem down to the smallest source code that produces this error, and to document the error for others to avoid.
Posted on 2002-07-26 21:29:42 by bitRAKE