Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 3 of 3

Thread: "uninitialized value" error

  1. #1
    Intern Newbie
    Join Date
    Nov 2013
    Posts
    43

    "uninitialized value" error

    I am writing a large (10,000+lines of code) program with extensive use of pointers and dynamic memory allocation. I also have interactive windows. Consequently, I am relying heavily on valgrind http://valgrind.org/ for memory diagnostics.
    I am getting the following the following diagnostic:
    ==8663== Conditional jump or move depends on uninitialised value(s)
    ==8663== at 0x4C32EA6: rawmemchr (vg_replace_strmem.c:1402)
    ==8663== by 0x5903391: _IO_str_init_static_internal (strops.c:41)
    ==8663== by 0x58F6B66: vsscanf (iovsscanf.c:40)
    ==8663== by 0x58F12D6: sscanf (sscanf.c:32)
    ==8663== by 0x7E52E4A: ??? (in /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0)
    ==8663== by 0x7E53182: ??? (in /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0)
    ==8663== by 0x7E56BF8: drmGetDevice (in /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0)
    ==8663== by 0x56662D6: ??? (in /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0)
    ==8663== by 0x5665694: ??? (in /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0)
    ==8663== by 0x5639988: ??? (in /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0)
    ==8663== by 0x5635541: glXGetFBConfigs (in /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0)
    ==8663== by 0x56368D1: glXChooseFBConfig (in /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0)
    ==8663== Uninitialised value was created by a stack allocation
    ==8663== at 0x7E52D9D: ??? (in /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0)
    ==8663==
    Does anyone have a clue as to what is happening?

    When I close the program, I get:

    HEAP SUMMARY:
    ==8663== in use at exit: 5,674,776 bytes in 135,608 blocks
    ==8663== total heap usage: 194,690 allocs, 59,082 frees, 98,989,029 bytes allocated
    ==8663==
    ==8663== 63 bytes in 4 blocks are definitely lost in loss record 37 of 116
    ==8663== at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
    ==8663== by 0x590D389: strdup (strdup.c:42)
    ==8663== by 0x9F1CB2A: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x9F1ECDE: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x9F2873B: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x9DC147E: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x9EAB832: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x9FFB945: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x9FFC407: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x9FB6A97: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x42B052: init (gnutran.c:6793)
    ==8663== by 0x4411F8: main (gnutran.c:9860)
    ==8663==
    ==8663== 63 bytes in 4 blocks are definitely lost in loss record 38 of 116
    ==8663== at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
    ==8663== by 0x590D389: strdup (strdup.c:42)
    ==8663== by 0x9F1CB2A: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x9F1ECDE: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x9F2873B: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x9DC147E: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x9EAB832: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x9FFB945: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x9FFC407: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x9FB6A97: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x440E9C: displayText (gnutran.c:9789)
    ==8663== by 0x441086: reshapeText (gnutran.c:9826)
    ==8663==
    ==8663== 2,376 (64 direct, 2,312 indirect) bytes in 1 blocks are definitely lost in loss record 90 of 116
    ==8663== at 0x4C2DBC5: calloc (vg_replace_malloc.c:711)
    ==8663== by 0xA3FC3D9: ??? (in /usr/lib/x86_64-linux-gnu/libdrm_intel.so.1.0.0)
    ==8663== by 0xA3FC7D2: ??? (in /usr/lib/x86_64-linux-gnu/libdrm_intel.so.1.0.0)
    ==8663== by 0xA033788: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x9DED3CB: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x9D0555B: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x9FC0B65: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x9F63C73: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x56652DE: ??? (in /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0)
    ==8663== by 0x5665392: ??? (in /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0)
    ==8663== by 0x563510A: ??? (in /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0)
    ==8663== by 0x56357B6: glXCreateNewContext (in /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0)
    ==8663==
    ==8663== 4,640 (56 direct, 4,584 indirect) bytes in 1 blocks are definitely lost in loss record 95 of 116
    ==8663== at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
    ==8663== by 0x9F6409C: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
    ==8663== by 0x5669651: ??? (in /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0)
    ==8663== by 0x566500E: ??? (in /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0)
    ==8663== by 0x565EE57: ??? (in /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0)
    ==8663== by 0x5665522: ??? (in /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0)
    ==8663== by 0x5638434: glXMakeContextCurrent (in /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0)
    ==8663== by 0x5162EE9: fgOpenWindow (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
    ==8663== by 0x51617C3: fgCreateWindow (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
    ==8663== by 0x516325F: glutCreateWindow (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
    ==8663== by 0x44115F: main (gnutran.c:9846)

  2. #2
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,167
    A few thoughts:

    • Are you using the default suppressions?
    • For the first error, are you properly initializing all of the arguments you're passing to glXChooseFBConfig?
    • The last 3 errors appear to be memory leaks down inside the Intel i965 DRI layer. Are you unbinding and destroying your context before you quit? If not, I wouldn't worry about them unless the amount of memory reported here is non-trivial.
    • Can you produce these problems (particularly problem #1) in a small stand-alone test program? If so, you could consider asking about them on the relevant forum or mailing list, posting the source snippet to solicit feedback (e.g. Mesa i965, if you're using Mesa).

  3. #3
    Intern Newbie
    Join Date
    Nov 2013
    Posts
    43
    I'm really not worried about the memory usage at shutdown. I have extensive cleanup when I open a different data file.
    Apparently my 10,000 line program is not at fault (whew!). I get the same uninitialized value with the following program:

    Code :
    // gl_hello.c
    // gcc -o gl_hello gl_hello.c -lglut
     
    #include <stdio.h>
    #include <stdlib.h>
    #include <GL/glew.h>
    //#include <GL/glext.h>
    #include <GL/glut.h>
     
    void display(){
        glClearColor(1.0f, 1.0f, 1.0f, 1.0f);
        glClear(GL_COLOR_BUFFER_BIT);
        glutSwapBuffers();
    }
     
    int WindowWidth=200, WindowHeight = 200, mainWindow;
     
    int main(int argc, char* argv[])
    {
      int i;
     
      glutInit(&argc,argv);
      glutInitDisplayMode (GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH);
    //    glutInitDisplayMode (GLUT_SINGLE | GLUT_RGB);
      glutInitWindowSize(WindowWidth, WindowHeight);
      glutInitWindowPosition(100, 100);
    //  mainWindow = glutCreateWindow(argv[1]);
      mainWindow = glutCreateWindow("Hello World");
    //  glutReshapeFunc(reshape);
        GLenum err = glewInit();
        if (GLEW_OK != err){
          // Problem: glewInit failed, something is seriously wrong.
          fprintf(stderr, "Error: %s\n", glewGetErrorString(err));
        }
    //  init();
      glutDisplayFunc(display);
    //    glutReshapeFunc (myReshape);
        glutMainLoop();
    //  atexit(bye);
      return(0);
    }
    valgrind --leak-check=full --track-origins=yes ./a.out

    I simply never thought to analyze it with valgrind before.


    Quote Originally Posted by Dark Photon View Post
    A few thoughts:

    • Are you using the default suppressions?
    • For the first error, are you properly initializing all of the arguments you're passing to glXChooseFBConfig?
    • The last 3 errors appear to be memory leaks down inside the Intel i965 DRI layer. Are you unbinding and destroying your context before you quit? If not, I wouldn't worry about them unless the amount of memory reported here is non-trivial.
    • Can you produce these problems (particularly problem #1) in a small stand-alone test program? If so, you could consider asking about them on the relevant forum or mailing list, posting the source snippet to solicit feedback (e.g. Mesa i965, if you're using Mesa).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •