Uninitiated variables in i965_dri.so

[wmelgaard]

I use the Valgrind memory leak checker (valgrind.org).

gcc hello_world.c -g -O0 -lglut -lGL
valgrind --leak-check=full --track-origins=yes ./a.out

produces an overflowing page of error messages, of which the following is an example

==2622== Invalid write of size 8
==2622== at 0x7207CD6: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==2622== by 0x72206A0: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==2622== by 0x72298B0: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==2622== by 0x6E7EA28: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==2622== by 0x4A31B41: glutBitmapCharacter (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
==2622== by 0x15120E: toolbar (in /home/william/projects/a.out)
==2622== by 0x15238A: display (in /home/william/projects/a.out)
==2622== by 0x154333: reshape (in /home/william/projects/a.out)
==2622== by 0x4A39F44: glutMainLoopEvent (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
==2622== by 0x4A3A6A4: glutMainLoop (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
==2622== by 0x154623: main (in /home/william/projects/a.out)
==2622== Address 0x7f4731d1705c is not stack’d, malloc’d or (recently) free’d
==2622==
==2622== Invalid write of size 4
==2622== at 0x7207CDE: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==2622== by 0x72206A0: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==2622== by 0x72298B0: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==2622== by 0x6E7EA28: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==2622== by 0x4A31B41: glutBitmapCharacter (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
==2622== by 0x15120E: toolbar (in /home/william/projects/a.out)
==2622== by 0x15238A: display (in /home/william/projects/a.out)
==2622== by 0x154333: reshape (in /home/william/projects/a.out)
==2622== by 0x4A39F44: glutMainLoopEvent (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
==2622== by 0x4A3A6A4: glutMainLoop (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0)
==2622== by 0x154623: main (in /home/william/projects/a.out)
==2622== Address 0x7f4731d17064 is not stack’d, malloc’d or (recently) free’d

I am running 4.18.0-2-amd64 #1 SMP Debian 4.18.10-2 (2018-11-02) x86_64 GNU/Linux
the time stamp on /usr/include/GL/gl.h and /usr/include/GL/glext.h is 10/10/18

I installed the binary version of OpenGL via apt. If I knew how to compile it from source, I would attempt to debug the .so .

What is the

[Dark_Photon]

Does your program run properly, or does it crash in glutBitmapCharacter()?

If the former, it’s not unusual for graphics drivers to do things which trigger warnings deep down in the graphics driver in valgrind. If you’re sure an error isn’t due to an error on your part or a bug in the graphics driver, you can add a suppression to mask it in the future.

This seems to suggest that if you want Mesa3D graphics drivers to run without valgrind errors, you nmay need to build in valgrind support.

[wmelgaard]

The Hello World trivial program does run without noticeable error. I encountered the problem on my laptop, which is an Intel machine. I ran the Hello World program under Valgrind on my desktop machine, which is an AMD machine, without any error messages. The problem is the Intel driver.
The only issue that I have is that the error messages scroll off the page, which blankets errors that I am really concerned with.
My reason for posting here is that I know of no better avenue for notifying concerned parties.

[QUOTE=Dark Photon;1293418]Does your program run properly, or does it crash in glutBitmapCharacter()?

If the former, it’s not unusual for graphics drivers to do things which trigger warnings deep down in the graphics driver in valgrind. If you’re sure an error isn’t due to an error on your part or a bug in the graphics driver, you can add a suppression to mask it in the future.

This seems to suggest that if you want Mesa3D graphics drivers to run without valgrind errors, you nmay need to build in valgrind support.[/QUOTE]