Jump to content

  • Log In with Google      Sign In   
  • Create Account


very strange bug (when runing c basic arrays code)

  • This topic is locked This topic is locked
40 replies to this topic

#21 phantom   Moderators   -  Reputation: 6875

Like
5Likes
Like

Posted 30 June 2014 - 12:10 PM

No, it's not a matter of 'what values' it's a matter of YOU learning to use the RIGHT TOOLS to debug this.

Given the call stack, memory dumps and other information this would probably be trivial to work out - use the right tool and stop trying to get others to debug things blindly for you.

This kind of thing is PRECISELY why the tools exist.
(Same with using a real profiler to work out performance problems.)

Sponsor:

#22 fir   Members   -  Reputation: -448

Like
-2Likes
Like

Posted 30 June 2014 - 12:30 PM


this is assembly output 

 

 
 
.file "tests.c"
.section .rdata,"dr"
LC0:
.ascii "yo1\0"
LC1:
.ascii "yo2\0"
LC2:
.ascii "yo3\0"
LC3:
.ascii "ay\0"
.text
.p2align 4,,15
.globl __Z14matrix_mul_ssev
.def __Z14matrix_mul_ssev; .scl 2; .type 32; .endef
__Z14matrix_mul_ssev:
pushl %ebx
xorl %ebx, %ebx
subl $168, %esp
movl $LC0, (%esp)
call __Z5alertPcz
movaps _modelRight_4x, %xmm0
movl $LC1, (%esp)
movaps %xmm0, 16(%esp)
call __Z5alertPcz
movaps _modelRight_4y, %xmm0
movl $LC2, (%esp)
movaps %xmm0, 32(%esp)
call __Z5alertPcz
movaps _modelRight_4z, %xmm0
movaps %xmm0, 48(%esp)
movaps _modelUp_4x, %xmm0
movaps %xmm0, 64(%esp)
movaps _modelUp_4y, %xmm0
movaps %xmm0, 80(%esp)
movaps _modelUp_4z, %xmm0
movaps %xmm0, 96(%esp)
movaps _modelDir_4x, %xmm0
movaps %xmm0, 112(%esp)
movaps _modelDir_4y, %xmm0
movaps %xmm0, 128(%esp)
movaps _modelDir_4z, %xmm0
movaps %xmm0, 144(%esp)
.p2align 4,,7
L2:
movl $LC3, (%esp)
call __Z5alertPcz
movaps _n_x(,%ebx,4), %xmm0
movaps _n_y(,%ebx,4), %xmm3
movaps 32(%esp), %xmm5
movaps 16(%esp), %xmm2
mulps %xmm3, %xmm5
movaps _n_z(,%ebx,4), %xmm4
mulps %xmm0, %xmm2
movaps 48(%esp), %xmm1
mulps %xmm4, %xmm1
movaps 80(%esp), %xmm6
addps %xmm5, %xmm2
mulps %xmm3, %xmm6
movaps 96(%esp), %xmm5
addps %xmm1, %xmm2
movaps 64(%esp), %xmm1
mulps %xmm4, %xmm5
movaps %xmm2, _normal_x(,%ebx,4)
mulps %xmm0, %xmm1
mulps 128(%esp), %xmm3
mulps 112(%esp), %xmm0
addps %xmm6, %xmm1
mulps 144(%esp), %xmm4
addps %xmm5, %xmm1
addps %xmm3, %xmm0
movaps %xmm1, _normal_y(,%ebx,4)
addps %xmm4, %xmm0
movaps %xmm0, _normal_z(,%ebx,4)
addl $4, %ebx
cmpl $100000, %ebx
jne L2
addl $168, %esp
popl %ebx
ret
.p2align 4,,15
.globl __Z5testsv
.def __Z5testsv; .scl 2; .type 32; .endef
__Z5testsv:
subl $28, %esp
call __Z14matrix_mul_ssev
movl $0, (%esp)
call _exit
.globl _modelDir_4z
.data
.align 16
_modelDir_4z:
.long 1067869798
.long 1067869798
.long 1067869798
.long 1067869798
.globl _modelDir_4y
.align 16
_modelDir_4y:
.long 1067030938
.long 1067030938
.long 1067030938
.long 1067030938
.globl _modelDir_4x
.align 16
_modelDir_4x:
.long 1066192077
.long 1066192077
.long 1066192077
.long 1066192077
.globl _modelUp_4z
.align 16
_modelUp_4z:
.long 1067869798
.long 1067869798
.long 1067869798
.long 1067869798
.globl _modelUp_4y
.align 16
_modelUp_4y:
.long 1067030938
.long 1067030938
.long 1067030938
.long 1067030938
.globl _modelUp_4x
.align 16
_modelUp_4x:
.long 1066192077
.long 1066192077
.long 1066192077
.long 1066192077
.globl _modelRight_4z
.align 16
_modelRight_4z:
.long 1067869798
.long 1067869798
.long 1067869798
.long 1067869798
.globl _modelRight_4y
.align 16
_modelRight_4y:
.long 1067030938
.long 1067030938
.long 1067030938
.long 1067030938
.globl _modelRight_4x
.align 16
_modelRight_4x:
.long 1066192077
.long 1066192077
.long 1066192077
.long 1066192077
.globl _n_z
.bss
.align 16
_n_z:
.space 400000
.globl _n_y
.align 16
_n_y:
.space 400000
.globl _n_x
.align 16
_n_x:
.space 400000
.globl _normal_z
.align 16
_normal_z:
.space 400000
.globl _normal_y
.align 16
_normal_y:
.space 400000
.globl _normal_x
.align 16
_normal_x:
.space 400000
.globl _modelDir_z
.data
.align 4
_modelDir_z:
.long 1067869798
.globl _modelDir_y
.align 4
_modelDir_y:
.long 1067030938
.globl _modelDir_x
.align 4
_modelDir_x:
.long 1066192077
.globl _modelUp_z
.align 4
_modelUp_z:
.long 1067869798
.globl _modelUp_y
.align 4
_modelUp_y:
.long 1067030938
.globl _modelUp_x
.align 4
_modelUp_x:
.long 1066192077
.globl _modelRight_z
.align 4
_modelRight_z:
.long 1067869798
.globl _modelRight_y
.align 4
_modelRight_y:
.long 1067030938
.globl _modelRight_x
.align 4
_modelRight_x:
.long 1066192077
.def __Z5alertPcz; .scl 2; .type 32; .endef
.def _exit; .scl 2; .type 32; .endef
 

Edited by fir, 30 June 2014 - 12:41 PM.


#23 fir   Members   -  Reputation: -448

Like
-1Likes
Like

Posted 30 June 2014 - 12:44 PM

 
 
for this code
 
void matrix_mul_sse()
{
 
  alert("yo1");
 
   __m128 mRx = _mm_load_ps((float*) &modelRight_4x);
 
  alert("yo2");
 
   __m128 mRy = _mm_load_ps((const float*) &modelRight_4y);
 
  alert("yo3");
 
   __m128 mRz = _mm_load_ps((const float*) &modelRight_4z);
   __m128 mUx = _mm_load_ps((const float*) &modelUp_4x);
   __m128 mUy = _mm_load_ps((const float*) &modelUp_4y);
   __m128 mUz = _mm_load_ps((const float*) &modelUp_4z);
   __m128 mDx = _mm_load_ps((const float*) &modelDir_4x);
   __m128 mDy = _mm_load_ps((const float*) &modelDir_4y);
   __m128 mDz = _mm_load_ps((const float*) &modelDir_4z);
 
  for(int i=0; i<100*1000; i+=4)
  {
 
    alert("ay");
 
   __m128 nx = _mm_load_ps( &n_x[i]);
   __m128 ny = _mm_load_ps( &n_y[i]);
   __m128 nz = _mm_load_ps( &n_z[i]);
 
   __m128 normalx = _mm_add_ps(_mm_add_ps(_mm_mul_ps(nx,mRx), _mm_mul_ps(ny,mRy)), _mm_mul_ps(nz,mRz));
   __m128 normaly = _mm_add_ps(_mm_add_ps(_mm_mul_ps(nx,mUx), _mm_mul_ps(ny,mUy)), _mm_mul_ps(nz,mUz));
   __m128 normalz = _mm_add_ps(_mm_add_ps(_mm_mul_ps(nx,mDx), _mm_mul_ps(ny,mDy)), _mm_mul_ps(nz,mDz));
 
    _mm_store_ps(  normal_x + i, normalx );
    _mm_store_ps(  normal_y + i, normaly );
    _mm_store_ps(  normal_z + i, normalz );
 
 }
 
}
 
void tests()
{
    matrix_mul_sse();
 
    exit(0);
 
}
 
 
 
this semms that compiler is reading the data to xmm then stores to the stack, maybe this stack is unaligned or something? i thought that it will keep it in registers - the thing of reading things to xmm0 and then storing this to local variables seem like a waste,
 
is the esp misalignment the reason?

 

 

 

*ps some bug makes code tags very annoying

 

 

PS this seems that really this is a reazon 

 

__m128 mRx ... 

 

values are unaligned on stack, how it could be such stupid?

 

is there some explanation for this?

 

 

 


Edited by fir, 30 June 2014 - 12:50 PM.


#24 Madhed   Crossbones+   -  Reputation: 2649

Like
0Likes
Like

Posted 30 June 2014 - 12:50 PM

there are only 8 xmm registers (16 in 64 bit mode).

 

At the beginning you are already calling _mm_load_ps 10 times.



#25 Tribad   Members   -  Reputation: 828

Like
1Likes
Like

Posted 30 June 2014 - 12:52 PM

The callstack is of interest because it maybe corrupted by some operation that you dont see at the moment. Maybe the stack-frame is corrupted or something else is wrong. The debugger maybe shows you other information, exceptions or the like. Because of the nature of optimized code noone will debug assembler output that the compiler generates after doing massive optimizations because the assembler statements are normally little correlate with the source code.

 

So dont expect anyone to look into a bunch of assembler statements to tell you whats wrong with it.



#26 fir   Members   -  Reputation: -448

Like
-1Likes
Like

Posted 30 June 2014 - 12:54 PM

there are only 8 xmm registers (16 in 64 bit mode).

 

At the beginning you are already calling _mm_load_ps 10 times.

i forgot this, sad 8 is not much - but still there is this unalignment problem - this seem abnormal to not align this on stack



#27 fir   Members   -  Reputation: -448

Like
0Likes
Like

Posted 30 June 2014 - 12:58 PM

The callstack is of interest because it maybe corrupted by some operation that you dont see at the moment. Maybe the stack-frame is corrupted or something else is wrong. The debugger maybe shows you other information, exceptions or the like. Because of the nature of optimized code noone will debug assembler output that the compiler generates after doing massive optimizations because the assembler statements are normally little correlate with the source code.

 

So dont expect anyone to look into a bunch of assembler statements to tell you whats wrong with it.

 

not so unclear - i got more weak medium assembly skills but thi is not so hard

 

movaps _modelRight_4x, %xmm0
movaps %xmm0, 16(%esp)
 

movaps _modelRight_4y, %xmm0
movaps %xmm0, 32(%esp)
 

movaps _modelRight_4z, %xmm0
movaps
%xmm0, 48(%esp)
 

movaps _modelUp_4x, %xmm0
movaps
%xmm0, 64(%esp)
 

movaps _modelUp_4y, %xmm0
movaps
%xmm0, 80(%esp)
 

movaps _modelUp_4z, %xmm0
movaps
%xmm0, 96(%esp)
 

movaps _modelDir_4x, %xmm0
movaps
%xmm0, 112(%esp)
 

movaps _modelDir_4y, %xmm0
movaps
%xmm0, 128(%esp)
 

movaps _modelDir_4z, %xmm0
movaps
%xmm0, 144(%esp)

 

this was generated for 

 

  __m128 mRx = _mm_load_ps((float*) &modelRight_4x);

   __m128 mRy = _mm_load_ps((const float*) &modelRight_4y);
   __m128 mRz = _mm_load_ps((const float*) &modelRight_4z);
   __m128 mUx = _mm_load_ps((const float*) &modelUp_4x);
   __m128 mUy = _mm_load_ps((const float*) &modelUp_4y);
   __m128 mUz = _mm_load_ps((const float*) &modelUp_4z);
   __m128 mDx = _mm_load_ps((const float*) &modelDir_4x);
   __m128 mDy = _mm_load_ps((const float*) &modelDir_4y);
   __m128 mDz = _mm_load_ps((const float*) &modelDir_4z);



#28 Tribad   Members   -  Reputation: 828

Like
0Likes
Like

Posted 30 June 2014 - 01:03 PM

try to add a volatile local variable onto the stack and make same fancy declspecs to align it on 16Bytes.

Maybe the compiler places the locals behind the variable.

 

It would be important to tell the compiler not to remove the 16Byte aligned local variable.



#29 phantom   Moderators   -  Reputation: 6875

Like
13Likes
Like

Posted 30 June 2014 - 01:27 PM

i forgot this, sad 8 is not much - but still there is this unalignment problem - this seem abnormal to not align this on stack


Maybe it is aligned.
Maybe it isn't.

Do you know what would tell you?

A DEBUGGER

It REALLY isn't that hard...

#30 fir   Members   -  Reputation: -448

Like
-8Likes
Like

Posted 30 June 2014 - 01:31 PM

 

i forgot this, sad 8 is not much - but still there is this unalignment problem - this seem abnormal to not align this on stack


Maybe it is aligned.
Maybe it isn't.

Do you know what would tell you?

A DEBUGGER

It REALLY isn't that hard...

 

i checked this in runtime - it was not aligned - do not propaganda me as this is boring me and is invaluable  - do i propaganda you to use or not to use something ? that would be silly imo,  this is yr choice i think - so use whatever you want but not bore me

 

- the point is different - why it is unaligned and how to align this?


Edited by fir, 30 June 2014 - 01:34 PM.


#31 Tribad   Members   -  Reputation: 828

Like
0Likes
Like

Posted 30 June 2014 - 01:33 PM

How?



#32 phantom   Moderators   -  Reputation: 6875

Like
15Likes
Like

Posted 30 June 2014 - 01:35 PM

No, this isn't "propaganda" this is a basic skill requirement for any programmer.

Learn to use a debugger and you can solve problems like this in no time.

Your out right refusal to learn to use the basic tools for the trade is wasting yours, and more importantly, everyone else's time and if it wasn't for the fact I'm involved in this thread I'd close it right now because you do not deserve the community's time and help because you refuse to pick up even the basic level of competence in the tools for the trade.

#33 fir   Members   -  Reputation: -448

Like
-5Likes
Like

Posted 30 June 2014 - 01:40 PM

No, this isn't "propaganda" this is a basic skill requirement for any programmer.

Learn to use a debugger and you can solve problems like this in no time.

Your out right refusal to learn to use the basic tools for the trade is wasting yours, and more importantly, everyone else's time and if it wasn't for the fact I'm involved in this thread I'd close it right now because you do not deserve the community's time and help because you refuse to pick up even the basic level of competence in the tools for the trade.

 

You are changing the topic on debuggers (something i dont want to talk because of lacks of time and interestment) 

 

Imo if you want to diskuss that topic you shoul open new thread and talk with interested persons 



#34 Juliean   GDNet+   -  Reputation: 2351

Like
6Likes
Like

Posted 30 June 2014 - 01:44 PM


You are changing the topic on debuggers (something i dont want to talk because of lacks of time and interestment)

 

If you have lack of time and interest to learn how to use debuggers, quit programming. Now.


Edited by Juliean, 30 June 2014 - 01:46 PM.


#35 Bacterius   Crossbones+   -  Reputation: 8287

Like
5Likes
Like

Posted 30 June 2014 - 01:50 PM

Okay. Not wanting to learn to use a debugger is the straw that broke the camel's back. I will not be replying to any of your threads in the future, fir - I've been patient, but I'm just about through with you. If other people somehow still want to help you after reading through your recent threads, it is their time to waste. I am not wishing you good luck, for you obviously will not need it, being too cool for debuggers and, in fact, anyone's advice that goes against your preconceptions. Do not bother replying to this post.


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#36 fir   Members   -  Reputation: -448

Like
-3Likes
Like

Posted 30 June 2014 - 01:54 PM

 


You are changing the topic on debuggers (something i dont want to talk because of lacks of time and interestment)

 

If you have lack of time and interest to learn how to use debuggers, quit programming. Now.

 

Im interestuing in this alignment bug got not time for discussing debuggers hera & today

 

well, ok,  two words but really i dont wonna discuss this today

 

1) im not against them but im not feeling terribly uncomfortable without them - maybe next month

 

2) im using simple text editor and commandline gcc and i dubt if i will find debugger that would integrate with this

 

3) im ussing assembly level olly debug (thats fine thing but not when searching normal bugs)

 

4) im using message boxes when need - but really the case when i need them is fortunately  rare thing 



#37 Tribad   Members   -  Reputation: 828

Like
3Likes
Like

Posted 30 June 2014 - 02:01 PM

fir does not use debuggers because he do not have bugs in the software he is writing. Only misbehaviour of compilers, operating systems and a complete misinterpretation of the language specification from the compiler vendors forcing him to analyze the resulting binary only and how it came to strange results the binary produces.

 

*sarcasm off*



#38 StaticPoof   Members   -  Reputation: 243

Like
5Likes
Like

Posted 30 June 2014 - 02:11 PM

Not to harp on you or anything, but you could literally step through every line in your code with a debugger and see which one is breaking your program.  They're not that hard to use and there are TONS of tutorials online.  

You've said repeatedly in this thread that you only want to find the alignment bug, but you keep refusing to use the tool that's specifically designed to do this.  

Debuggers help you find and fix bugs quickly



#39 Lactose!   GDNet+   -  Reputation: 3046

Like
7Likes
Like

Posted 30 June 2014 - 02:16 PM


Debuggers help you find and fix bugs quickly

It's almost as if the name of the tool was a hint to what it should be used for.



#40 ApochPiQ   Moderators   -  Reputation: 14623

Like
6Likes
Like

Posted 30 June 2014 - 02:25 PM

Fir, this is your last chance. Fix your horrific attitude or you're done with GDNet.





PARTNERS