Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
104 user(s) are online (52 user(s) are browsing Forums)

Members: 1
Guests: 103

flash, more...

Headlines

 
  Register To Post  

(1) 2 3 4 »
Why call to or any "empty" functions cause different results of the other code execution ? FIXED!
Home away from home
Home away from home


See User information
@all

Have some interesting theoretical questions. Over the years, from time to time, i find out in AmigaOS apps some strange issues, like adding the calling to any function (as a stub) inside of the code blocks, may cause different execution and results of that code block.

What i mean is:

some_function();
some_function();
printf("aa");
some_function();
some_function();


And sometimes, depends on having print, and not having print, cause different results of executed code.

I meet with that issues already 3-4 times in the last years in different projects and do not remember if i was able to fix it all and understand wtf.

All I understand is that once we have another call in the code, we have a) bigger text code segment b) slow the resources down for a mile second, so that can "fix" race condition issue or something.

For example, for now i have that :

...
    
shaders_supported SDL_FALSE;
    if (
SDL_GL_ExtensionSupported("GL_ARB_shader_objects") &&
        
SDL_GL_ExtensionSupported("GL_ARB_shading_language_100") &&
        
SDL_GL_ExtensionSupported("GL_ARB_vertex_shader") &&
        
SDL_GL_ExtensionSupported("GL_ARB_fragment_shader")) {

        
printf("aaaaa\n");
        
        
glAttachObjectARB = (PFNGLATTACHOBJECTARBPROCSDL_GL_GetProcAddress("glAttachObjectARB");
        
glCompileShaderARB = (PFNGLCOMPILESHADERARBPROCSDL_GL_GetProcAddress("glCompileShaderARB");
        
glCreateProgramObjectARB = (PFNGLCREATEPROGRAMOBJECTARBPROCSDL_GL_GetProcAddress("glCreateProgramObjectARB");
....


Having prints inside, make everything work. Commenting prints, make everything not work. As far as I remember, it doesn't matter much if it prinf() or any other place-holder function, the important bit is to call "something", and probably not just from amiga libs, but from the newlib/etc.

Have anyone any clue about ?


Edited by kas1e on 2022/3/2 11:58:45
Edited by kas1e on 2022/3/2 11:59:15
Edited by kas1e on 2022/3/12 11:28:47
Go to top
Re: Why "prinfs" or any functiosn can cause different results of the code blocks ?
Quite a regular
Quite a regular


See User information
This can be a sign of the optimizer doing something funny. Try to compile this file with -O0, or if the compiler supports it add __attribute__((optimize("O0"))) to the affected function. If that fixes the problem you can either leave that function unoptimized, or you can try to make problematic variables "volatile".

Go to top
Re: Why "prinfs" or any functiosn can cause different results of the code blocks ?
Home away from home
Home away from home


See User information
@BSzili
Tried with -O0, didn't help sadly.

I tried to replace printf() on just IDOS->Delay(1); , that also fixed the problem.

It all looks like some race condition or something. Or maybe that is the way the function pointer is gathered?


What is more interesting is that this all about exactly "whole" fuction, i can put call to other functions anywhere else to make whole logic of function work. There that piece of code:


static SDL_bool InitShaders()
{
    
int i;

    
/* Check for shader support */
    
shaders_supported SDL_FALSE;
    if (
SDL_GL_ExtensionSupported("GL_ARB_shader_objects") &&
        
SDL_GL_ExtensionSupported("GL_ARB_shading_language_100") &&
        
SDL_GL_ExtensionSupported("GL_ARB_vertex_shader") &&
        
SDL_GL_ExtensionSupported("GL_ARB_fragment_shader")) {

        
glAttachObjectARB = (PFNGLATTACHOBJECTARBPROCSDL_GL_GetProcAddress("glAttachObjectARB");
        
glCompileShaderARB = (PFNGLCOMPILESHADERARBPROCSDL_GL_GetProcAddress("glCompileShaderARB");
        
glCreateProgramObjectARB = (PFNGLCREATEPROGRAMOBJECTARBPROCSDL_GL_GetProcAddress("glCreateProgramObjectARB");
        
glCreateShaderObjectARB = (PFNGLCREATESHADEROBJECTARBPROCSDL_GL_GetProcAddress("glCreateShaderObjectARB");
        
glDeleteObjectARB = (PFNGLDELETEOBJECTARBPROCSDL_GL_GetProcAddress("glDeleteObjectARB");
        
glGetInfoLogARB = (PFNGLGETINFOLOGARBPROCSDL_GL_GetProcAddress("glGetInfoLogARB");
        
glGetObjectParameterivARB = (PFNGLGETOBJECTPARAMETERIVARBPROCSDL_GL_GetProcAddress("glGetObjectParameterivARB");
        
glGetUniformLocationARB = (PFNGLGETUNIFORMLOCATIONARBPROCSDL_GL_GetProcAddress("glGetUniformLocationARB");
        
glLinkProgramARB = (PFNGLLINKPROGRAMARBPROCSDL_GL_GetProcAddress("glLinkProgramARB");
        
glShaderSourceARB = (PFNGLSHADERSOURCEARBPROCSDL_GL_GetProcAddress("glShaderSourceARB");
        
glUniform1iARB = (PFNGLUNIFORM1IARBPROCSDL_GL_GetProcAddress("glUniform1iARB");
        
glUseProgramObjectARB = (PFNGLUSEPROGRAMOBJECTARBPROCSDL_GL_GetProcAddress("glUseProgramObjectARB");

        
        if (
glAttachObjectARB &&
            
glCompileShaderARB &&
            
glCreateProgramObjectARB &&
            
glCreateShaderObjectARB &&
            
glDeleteObjectARB &&
            
glGetInfoLogARB &&
            
glGetObjectParameterivARB &&
            
glGetUniformLocationARB &&
            
glLinkProgramARB &&
            
glShaderSourceARB &&
            
glUniform1iARB &&
            
glUseProgramObjectARB) {
            
shaders_supported SDL_TRUE;
        }
    }

    if (!
shaders_supported) {
        
//printf("shaders support false!\n");
        
return SDL_FALSE;
    }

        
IDOS->Delay(1);

    
/* Compile all the shaders */
    
for (0NUM_SHADERS; ++i) {
        if (!
CompileShaderProgram(&shaders[i])) {
            
//printf("but compile shaders fail!\n");
            
SDL_LogError(SDL_LOG_CATEGORY_APPLICATION"Unable to compile shader!\n");
            return 
SDL_FALSE;
        }
    }


    
/* We're done! */
    
return SDL_TRUE;
}


See, i even can put Delay(1) before compiling all the shaders, and then it all start to works..

Go to top
Re: Why "prinfs" or any functiosn can cause different results of the code blocks ?
Home away from home
Home away from home


See User information
@kas1e

I'm not near anything you can do in AmigaOS compiling/writing/coding, so I don't think I can add anything valuable to this thread, but I'll still try.

This (and what you wrote on ptitseb thread) sounds like a race condition, probably limited to our platform, maybe even our gfx driver/ogles2 (or SDL2?).

Since you tried with both a printf and a delay it looks like it always needs some sort of delay to make the code work (after GL stuff), even if it's just a milisecond(?)

Since we have some sort of workaround already (delay), you could maybe create a short example and ask Hans/Daytona?

Not much help, sorry

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Home away from home
Home away from home


See User information
@Raziel
What happens back in time for me for some other stuff, where if I remember right GL wasn't involved, but can't be sure. But what for sure, that it is not the first time.

But i also think it's some kind of race condition when something is just not fast enough.

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just popping in
Just popping in


See User information
It may also just be that your magic function (Delay() or printf()) triggers some linker autoinit stuff which is otherwise not happening.

What happens if you put the Delay() or printf() in some place in the .c file which never gets called. Or inside some check which never is true (but make sure it's not something the compiler optimizes away completely). Like "if (SysBase->SysFlags == 0xABCD)"

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Home away from home
Home away from home


See User information
@Georg
I just add before another function in the whole source, like:

static SDL_bool Omega1200(void)
{
IDOS->Delay(1);    
}


And nope, didn't work.

Interesting that if i add instead of Delay or Printf that:

for (0100000000; ++i) {

    }


Then while i clearly see pause visually, it still didn't make it works. So that is not "pause" per se fix it.

I also tried to use rand(); - no luck.

What is more fun, if i use small printf() like prinf("a"); then it also didn't fix issue, but more "a" i put, then it works.

And i 100% have the same kind of issue somewhere back in past. Exactly that kind, when "long" print fixes issues, but small are not. If i remember right i fix it only by restructuring the source or something, but still, never understand the root cause.

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Quite a regular
Quite a regular


See User information
@kas1e
Aha, so you had to introduce a small delay before compiling the shaders, I was completely off the mark. Is this is the program in question?
https://fossies.org/linux/SDL2/test/testshader.c
In this case it would be good to know at which point CompileShaderProgram returns FALSE.

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Home away from home
Home away from home


See User information
@BSzili
Yeah, this one. Probably wasn't changed much and the same as https://github.com/AmigaPorts/SDL-2.0/blob/main/test/testshader.c

Quote:

In this case it would be good to know at which point CompileShaderProgram returns FALSE.


If only I know :) Once i will start put _any_ printf things will start work.. I may try to comment out some parts, but then, the code will be shorter and may start to work without pointing us out on the issue.

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just popping in
Just popping in


See User information
Quote:

I just add before another function in the whole source, like:

static SDL_bool Omega1200(void)
{
IDOS->Delay(1);    
}



If the function never gets called it may be optimized away.

Quote:

What is more fun, if i use small printf() like prinf("a"); then it also didn't fix issue, but more "a" i put, then it works.


The compiler may have optimized printf() into a putchar().

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Quite a regular
Quite a regular


See User information
@kas1e
I don't necessarily mean printfs, but for example commenting out returns or setting a variable to the line number that you print later.

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Home away from home
Home away from home


See User information
@BSzili
Just tried to comment out in InitShaders() two "return SDL_FALSE;" => no luck. Also tried to rebuild it with GCC 8.4.0 and with 11.2.0 => the same result.

At the moment trying to short the test case as much as possible


EDIT: Don't know if i got any futher,or just looping on the same ring, but seems that issue actually coming from CompileShaderProgram() function in that test case. At least, if i add printfs() there, it also works then.

But i still can't get how it. Maybe some auto-paging of memory regions enables/disables by default..


Edited by kas1e on 2022/3/2 20:54:14
Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just popping in
Just popping in


See User information
@kas1e

Remember that while printf() looks simple in the source code, there's a lot going on under the hood, involving the console (which decides where the printed text goes), the graphics library (which renders the font characters into pixels), and the graphics card driver (which gets the pixels to the screen).

Somewhere in all of that there's almost certainly something that has to Wait(), which gives other tasks a chance to run. So printf() doesn't just take some time to execute. but it also allows other tasks to run. Your for() loop takes time, but most likely doesn't cause a task switch (assuming the delay isn't so long that it's preempted). Calling Delay() of course also allows other tasks to run, without all the other complexity of printf().

I'm not a 3D graphics guru, so I have no idea what those graphics calls are doing. But if it involves another task that's running asynchronously, then letting that task run while you're delaying may give it a chance to complete some necessary work that doesn't get done in time otherwise.

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Quite a regular
Quite a regular


See User information
@kas1e
Yeah, it's probably not a compiler issue, but likely related to something going in inside the opengl library. Did you try adding a global variable for CompileShaderProgram? Just set it to __LINE__ before every return, and print it in InitShaders. This way you'll have a better idea of which point it fails.

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just popping in
Just popping in


See User information
To me this does not look or "smell" like race condition or timing related at all. Add an always failing runtime checked (to make sure it can't be optimized away) check around printf call that usually makes the thing work and see what happens. If it still works even if the actual printf() call never gets executed then you know it's not timing/race condition problem.

- printf("blablabla")
+ if ((int)SysBase == 0x1234) printf("blablabla");

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Home away from home
Home away from home


See User information
@all
I also want to point out one more time, not only prinf("aa") fix the things, but also IDOS->Delay(1) too.

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Home away from home
Home away from home


See User information
@Georg
Ok, added
if ((int)SysBase == 0x1234printf("blablabla");


instead of prinfs => _NOT_ works. Once just printf() or delay(), then works. So still seems timing/race?

@Bszili
Quote:

Did you try adding a global variable for CompileShaderProgram? Just set it to __LINE__ before every return, and print it in InitShaders.


Sorry i am a bit lame to undestrand that all, can you show in the code how it will be ? I mean on that:

static SDL_bool InitShaders()
{
    
int i;

    
/* Check for shader support */
    
    
shaders_supported SDL_FALSE;
    
    if (
SDL_GL_ExtensionSupported("GL_ARB_shader_objects") &&
        
SDL_GL_ExtensionSupported("GL_ARB_shading_language_100") &&
        
SDL_GL_ExtensionSupported("GL_ARB_vertex_shader") &&
        
SDL_GL_ExtensionSupported("GL_ARB_fragment_shader")) 
            
        {

        
glAttachObjectARB = (PFNGLATTACHOBJECTARBPROCSDL_GL_GetProcAddress("glAttachObjectARB");
        
glCompileShaderARB = (PFNGLCOMPILESHADERARBPROCSDL_GL_GetProcAddress("glCompileShaderARB");
        
glCreateProgramObjectARB = (PFNGLCREATEPROGRAMOBJECTARBPROCSDL_GL_GetProcAddress("glCreateProgramObjectARB");
        
glCreateShaderObjectARB = (PFNGLCREATESHADEROBJECTARBPROCSDL_GL_GetProcAddress("glCreateShaderObjectARB");
        
glDeleteObjectARB = (PFNGLDELETEOBJECTARBPROCSDL_GL_GetProcAddress("glDeleteObjectARB");
        
glGetInfoLogARB = (PFNGLGETINFOLOGARBPROCSDL_GL_GetProcAddress("glGetInfoLogARB");
        
glGetObjectParameterivARB = (PFNGLGETOBJECTPARAMETERIVARBPROCSDL_GL_GetProcAddress("glGetObjectParameterivARB");
        
glGetUniformLocationARB = (PFNGLGETUNIFORMLOCATIONARBPROCSDL_GL_GetProcAddress("glGetUniformLocationARB");
        
glLinkProgramARB = (PFNGLLINKPROGRAMARBPROCSDL_GL_GetProcAddress("glLinkProgramARB");
        
glShaderSourceARB = (PFNGLSHADERSOURCEARBPROCSDL_GL_GetProcAddress("glShaderSourceARB");
        
glUniform1iARB = (PFNGLUNIFORM1IARBPROCSDL_GL_GetProcAddress("glUniform1iARB");
        
glUseProgramObjectARB = (PFNGLUSEPROGRAMOBJECTARBPROCSDL_GL_GetProcAddress("glUseProgramObjectARB");


        
shaders_supported SDL_TRUE;
        }
    

         
        if ((int)
SysBase == 0x1234printf("blablabla");
//        IDOS->Delay(1);
//         printf("aa");


    /* Compile all the shaders */
    
for (0NUM_SHADERS; ++i) {
        if (!
CompileShaderProgram(&shaders[i])) {
            
SDL_LogError(SDL_LOG_CATEGORY_APPLICATION"Unable to compile shader!\n");
            return 
SDL_FALSE;
        }
    }

    
/* We're done! */
    
return SDL_TRUE;
}

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Quite a regular
Quite a regular


See User information
@kas1e
For example something like:
static int linenum 0;

static 
SDL_bool CompileShaderProgram(ShaderData *data)
{
  (...)

  if (!
something)
  {
     
linenum __LINE__;
     return 
SDL_FALSE;
  }


  (...)

  
linenum __LINE__;
  return 
stuff SDL_TRUE SDL_FALSE;
}


static 
SDL_bool InitShaders()
{

  (...)

  if (!
CompileShaderProgram(...))
  {
     
printf("failed at line %d\n"linenum);
  }

}


Basically you add a linenum = __LINE__; before return statements to track where it returned.

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just popping in
Just popping in


See User information
Btw, what does "not work" mean? Does it crash? Does it quit?

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just popping in
Just popping in


See User information
IIRC in AROS I once had a funny situation in a some test program which opened a window and would quit when you press some key. In the shell you typed in the command, pressed RETURN key, the window opened quickly and the RETURN key release happened after that and so the event went to the window/test program which then quit immediately.

Go to top

  Register To Post
(1) 2 3 4 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project