• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
fir

very strange bug (when runing c basic arrays code)

40 posts in this topic

I was testing such very simple code 

float modelRight_x = 1.1;
float modelRight_y = 1.2;
float modelRight_z = 1.3;
 
float modelUp_x = 1.1;
float modelUp_y = 1.2;
float modelUp_z = 1.3;
 
float modelDir_x = 1.1;
float modelDir_y = 1.2;
float modelDir_z = 1.3;
 
 
 float normal_x[100*1000];
 float normal_y[100*1000];
 float normal_z[100*1000];
 
 float n_x[100*1000];
 float n_y[100*1000];
 float n_z[100*1000];
 
 
 
void matrix_mul_float()
{
  for(int i=0; i<100*1000; i++)
  {
 
    normal_x[i] = n_x[i]*modelRight_x + n_y[i]*modelRight_y + n_z[i]*modelRight_z;
    normal_y[i] = n_x[i]*modelUp_x    + n_y[i]*modelUp_y    + n_z[i]*modelUp_z;
 //third line ->
    normal_z[i] = n_x[i]*modelDir_x   + n_y[i]*modelDir_y   + n_z[i]*modelDir_z;
 
   }
 
  return;
 
}

(dam those forum bug eated text again)

 

I got runtime crash on the third line , when comment this line its ok, when xchange it with normal_x[i] = ... line it crashes on those x third line then, it also works when changing 

 

    normal_z[i/2] = n_x[i]*modelDir_x   + n_y[i]*modelDir_y   + n_z[i]*modelDir_z;

 
very strange imo
 

    normal_z[i/1*1] = n_x[i]*modelDir_x   + n_y[i]*modelDir_y   + n_z[i]*modelDir_z;

 

crashes

 

    normal_z[i/2*2] = n_x[i]*modelDir_x   + n_y[i]*modelDir_y   + n_z[i]*modelDir_z;

 
not crashes
 
compile options
 
c:\mingw\bin\g++ -O3 -Ofast -w -c tests.c  -funsafe-math-optimizations -mrecip -ffast-math -fno-rtti -fno-exceptions -march=pentium4 -mtune=generic -mfpmath=both 
 

gcc 4.7.1

 

is this compiler bug?

Edited by fir
0

Share this post


Link to post
Share on other sites

integer math:

 

5/1*1 = 5;

5/2*2 = 4; 5/2 = 2.5, the decimal is dropped with an integer, so you get 2*2 = 4.

 

re-check your allocation sizes, as the code you've posted shoudn't be crashing with those allocations.

Edited by slicer4ever
0

Share this post


Link to post
Share on other sites

Think it is compiler bug - also vanishes (not crashes) when turning  "-O3 -Ofast " into "-O2"

-1

Share this post


Link to post
Share on other sites

the fact that changing compiler settings "fixes" this bug likely indicates you've corrupted memory somewhere, and this is just where it's actually crashing.

0

Share this post


Link to post
Share on other sites
 

the fact that changing compiler settings "fixes" this bug likely indicates you've corrupted memory somewhere, and this is just where it's actually crashing.

 

byt this is just multiplication and addition code should work regardless of ram contents - what could be spoiled ? 

 

i got also crashes on such sse intrinsics code

 

 
void matrix_mul_sse()
{
 
   __m128 mRx = _mm_load_ps((const 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);
 
  for(int i=0; i<100*1000; i+=4)
  {
 
   __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);
 
 }
 
}

 
this not crashes but crashes when uncomment one of the commented lines
(as to this code i cannot be sure if this is ok as im very new to sse but also a bit strange) - [this crashes even when i got only -O2, not tested other cases]
Edited by fir
0

Share this post


Link to post
Share on other sites

100*1000 is 100,000 elements, 6 such arrays make 600,000 elements 4 bytes each, that's 2,400,000 bytes or over 2 MB. That's bigger than default stack size, that's why you get crash. Use new[] operator for those arrays and it'll work just fine.

2

Share this post


Link to post
Share on other sites

100*1000 is 100,000 elements, 6 such arrays make 600,000 elements 4 bytes each, that's 2,400,000 bytes or over 2 MB. That's bigger than default stack size, that's why you get crash. Use new[] operator for those arrays and it'll work just fine.

 

Assuming he didn't butcher the code completely when copying it, the arrays are defined at file scope and are not stack allocated. May still be a good idea to allocate them dynamically rather than statically though.

0

Share this post


Link to post
Share on other sites

100*1000 is 100,000 elements, 6 such arrays make 600,000 elements 4 bytes each, that's 2,400,000 bytes or over 2 MB. That's bigger than default stack size, that's why you get crash. Use new[] operator for those arrays and it'll work just fine.


It looks like those arrays are global variables, and in that case this should be fine.

I suggest trying to simplify the program (ideally until it's just that function and a main() that does enough to call it), removing everything you can until you have a program that wouldn't show the problem if you removed anything from it. If that's the case, post the complete minimal program so we can try to reproduce the problem ourselves. But there is a good chance you'll find the problem yourself in the process of making the minimal program.
0

Share this post


Link to post
Share on other sites
Allways compile -Wall and make sure you get no warnings. Warnings may differe with optimization levels.
0

Share this post


Link to post
Share on other sites
Can make the source available? Think its some tricky trick that lead to the behaviour.
0

Share this post


Link to post
Share on other sites

Can make the source available? Think its some tricky trick that lead to the behaviour.

 

the code is like i said

 

this is stripped to the bare win main version with the same settings to compilation

 

https://www.dropbox.com/s/ib4igh5qs85a156/test.zip

 

it do not crashes as it seem 

 

when I call it from within my program 

#include "fist.h"
#include <x86intrin.h>
 
 
float modelRight_x = 1.1;
float modelRight_y = 1.2;
float modelRight_z = 1.3;
 
float modelUp_x = 1.1;
float modelUp_y = 1.2;
float modelUp_z = 1.3;
 
float modelDir_x = 1.1;
float modelDir_y = 1.2;
float modelDir_z = 1.3;
 
 
 
__attribute__ ((aligned (16))) float normal_x[100*1000];
__attribute__ ((aligned (16))) float normal_y[100*1000];
__attribute__ ((aligned (16))) float normal_z[100*1000];
 
__attribute__ ((aligned (16))) float n_x[100*1000];
__attribute__ ((aligned (16))) float n_y[100*1000];
__attribute__ ((aligned (16))) float n_z[100*1000];
 
 
 
void initialize_data_for_matrix_mul()
{
 
 static int initialized = 0;
 if(initialized) return;
 initialized = 1;
 
 for(int i=0; i<100*1000; i++)
 {
  n_x[i] = (100.+rand()%10000)/1000.;
  n_y[i] = (100.+rand()%10000)/1000.;
  n_z[i] = (100.+rand()%10000)/1000.;
 }
 
}
 
void matrix_mul_float()
{
  for(int i=0; i<100*1000; i++)
  {
 
    normal_x[i] = n_x[i]*modelRight_x + n_y[i]*modelRight_y + n_z[i]*modelRight_z;
    normal_y[i] = n_x[i]*modelUp_x    + n_y[i]*modelUp_y    + n_z[i]*modelUp_z;
    normal_z[i] = n_x[i]*modelDir_x   + n_y[i]*modelDir_y   + n_z[i]*modelDir_z;
 
 
  }
  return;
 
}
 
//struct float4 { float x,y,z,w; };
 
 __attribute__ ((aligned (16))) float4 modelRight_4x = {1.1, 1.1, 1.1, 1.1 };
 __attribute__ ((aligned (16))) float4 modelRight_4y = {1.2, 1.2, 1.2, 1.2 };
 __attribute__ ((aligned (16))) float4 modelRight_4z = {1.3, 1.3, 1.3, 1.3 };
 
 __attribute__ ((aligned (16))) float4 modelUp_4x = {1.1, 1.1, 1.1, 1.1 };;
 __attribute__ ((aligned (16))) float4 modelUp_4y = {1.2, 1.2, 1.2, 1.2 };;
 __attribute__ ((aligned (16))) float4 modelUp_4z = {1.3, 1.3, 1.3, 1.3 };;
 
 __attribute__ ((aligned (16))) float4 modelDir_4x = {1.1, 1.1, 1.1, 1.1 };;
 __attribute__ ((aligned (16))) float4 modelDir_4y = {1.2, 1.2, 1.2, 1.2 };;
 __attribute__ ((aligned (16))) float4 modelDir_4z = {1.3, 1.3, 1.3, 1.3 };;
 
void matrix_mul_sse()
{
 
   __m128 mRx = _mm_load_ps((const 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);
 
  for(int i=0; i<100*1000; i+=4)
  {
 
   __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()
{
 
   alert("\nstart");
 
   initialize_data_for_matrix_mul();
 
   alert("\nmul float");
 
    matrix_mul_float();
 
   alert("\nmul sse");
 
    matrix_mul_sse();
 
    alert("\ndone");
 
   exit(0);
 
}
 

with only chnge changing winmain to tests and including header of my framework, should bo nothing scary there (i could comment this), - this is linked as an seperate .o and called - it crashes as i said

 

commented header thus calling the same code as this separate win main that not crashes - only change is the renaming winmain to tests and calling this from my appilication (commandline scripts are the same except im linking more objects in my application) - this just crashes when called from my application (I call it in the main loop, could see what would be there if i call it from app setup)

Edited by fir
0

Share this post


Link to post
Share on other sites

When it crashes what is the call stack?
What values to variables hold?
What is the content of the destination memory?
Is it what you expect?
What does the debugger tell you?

 

callstack is obvious i think

 

ps, im talking now about this second crash (not the first possibly more mysterious one, (that with simple float code) - as i just off -O3 -Ofast and skipped this)

 

here it seem crash on the first sse line

 

 

  alert_("yo1");
        // CRaSH HERE
   __m128 mRx = _mm_load_ps((const float*) &modelRight_4x);
 
  alert_("yo2");
walues are 16-aligned I checked them in runtime
-1

Share this post


Link to post
Share on other sites

100*1000 is 100,000 elements, 6 such arrays make 600,000 elements 4 bytes each, that's 2,400,000 bytes or over 2 MB. That's bigger than default stack size, that's why you get crash. Use new[] operator for those arrays and it'll work just fine.

 

You have your answer right there, stop blaming the compiler for your mistake. Either allocate the array with new(recommended) or increase the stack size. Default stack size is 1 Mb IIRC.

Edited by Vortez
0

Share this post


Link to post
Share on other sites

 


100*1000 is 100,000 elements, 6 such arrays make 600,000 elements 4 bytes each, that's 2,400,000 bytes or over 2 MB. That's bigger than default stack size, that's why you get crash. Use new[] operator for those arrays and it'll work just fine.

 

You have your answer right there, stop blaming the compiler for your mistake.

 

 

?

-1

Share this post


Link to post
Share on other sites

So, did you run a debugger yet?

what values you want to know - i will tel you

 

still got no idea what is the reason -

maybe this is some kind of sse mode i need to turn on or something?

 

i may say - i checked the _mm_loadu_ps and it crashes the same

also decrased the arrays size but it crashes the same

0

Share this post


Link to post
Share on other sites

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
-2

Share this post


Link to post
Share on other sites
 
 
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
-1

Share this post


Link to post
Share on other sites

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

 

At the beginning you are already calling _mm_load_ps 10 times.

0

Share this post


Link to post
Share on other sites

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.

1

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  
Followers 0