Dear bugzilla, I built the example program here: https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glXIntro.xml $ gcc -Wall -Wextra -o glxample glxample.c -lX11 -lGL (The test app works and shows a little yellow window then exits after 10 seconds as it is supposed to) I ran it under valgrind, with the relevant packages built unstripped. I found the same error, but from a different initial function, with xfwm4, while trying to resolve an issue with that in another as yet unresolved bug report, which includes that valgrind trace, and more os/hw details: https://bugzilla.xfce.org/show_bug.cgi?id=16032 I was intending to find a simple test app to try out the function glXQueryServerString to confirm if this problem was in mesa / libdrm but didn't even need to do that. Any ideas what is happening here, and if this apparent buffer overflow could be relevant to the xfwm4 bug, or something extra besides that? $ valgrind --tool=memcheck --fullpath-after=/home/name/debug-xwfm4 --num-callers=100 ./glxample ==3018== Memcheck, a memory error detector ==3018== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==3018== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==3018== Command: ./glxample ==3018== ==3018== Syscall param ioctl(generic) points to uninitialised byte(s) ==3018== at 0x4B3325B: ioctl (in /usr/lib/libc-2.30.so) ==3018== by 0x52280DE: drmIoctl (/symbolpkgs/libdrm/src/build/../libdrm-2.4.100/xf86drm.c:180) ==3018== by 0x52290F3: drmCommandWriteRead (/symbolpkgs/libdrm/src/build/../libdrm-2.4.100/xf86drm.c:2644) ==3018== by 0xC0679DA: nouveau_object_ioctl (/symbolpkgs/libdrm/src/build/../libdrm-2.4.100/nouveau/nouveau.c:88) ==3018== by 0xC068286: nouveau_object_init (/symbolpkgs/libdrm/src/build/../libdrm-2.4.100/nouveau/nouveau.c:262) ==3018== by 0xC06A55C: nouveau_device_new (/symbolpkgs/libdrm/src/build/../libdrm-2.4.100/nouveau/nouveau.c:389) ==3018== by 0x5D5D0AD: nouveau_drm_screen_create (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c:101) ==3018== by 0x5AD319A: pipe_nouveau_create_screen (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/auxiliary/target-helpers/drm_helper.h:76) ==3018== by 0x5B7186C: pipe_loader_drm_create_screen (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c:314) ==3018== by 0x5B7134E: pipe_loader_create_screen (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/auxiliary/pipe-loader/pipe_loader.c:128) ==3018== by 0x5AD6EA1: dri2_init_screen (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/state_trackers/dri/dri2.c:2036) ==3018== by 0x5AD4725: driCreateNewScreen2 (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/mesa/drivers/dri/common/dri_util.c:154) ==3018== by 0x51B7570: dri2CreateScreen (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/dri2_glx.c:1288) ==3018== by 0x51A80F0: AllocAndFetchScreenConfigs (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/glxext.c:817) ==3018== by 0x51A84C3: __glXInitialize (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/glxext.c:940) ==3018== by 0x51A49D7: glXGetFBConfigs (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/glxcmds.c:1660) ==3018== by 0x51A5099: glXChooseFBConfig (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/glxcmds.c:1599) ==3018== by 0x4C386F9: glXChooseFBConfig (in /usr/lib/libGLX.so.0.0.0) ==3018== by 0x109301: main (in /home/name/debug-xwfm4/glxample) ==3018== Address 0x4f1a382 is 2 bytes inside a block of size 72 alloc'd ==3018== at 0x483877F: malloc (/build/valgrind/src/valgrind/coregrind/m_replacemalloc/vg_replace_malloc.c:309) ==3018== by 0xC068237: nouveau_object_init (/symbolpkgs/libdrm/src/build/../libdrm-2.4.100/nouveau/nouveau.c:251) ==3018== by 0xC06A55C: nouveau_device_new (/symbolpkgs/libdrm/src/build/../libdrm-2.4.100/nouveau/nouveau.c:389) ==3018== by 0x5D5D0AD: nouveau_drm_screen_create (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c:101) ==3018== by 0x5AD319A: pipe_nouveau_create_screen (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/auxiliary/target-helpers/drm_helper.h:76) ==3018== by 0x5B7186C: pipe_loader_drm_create_screen (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c:314) ==3018== by 0x5B7134E: pipe_loader_create_screen (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/auxiliary/pipe-loader/pipe_loader.c:128) ==3018== by 0x5AD6EA1: dri2_init_screen (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/state_trackers/dri/dri2.c:2036) ==3018== by 0x5AD4725: driCreateNewScreen2 (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/mesa/drivers/dri/common/dri_util.c:154) ==3018== by 0x51B7570: dri2CreateScreen (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/dri2_glx.c:1288) ==3018== by 0x51A80F0: AllocAndFetchScreenConfigs (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/glxext.c:817) ==3018== by 0x51A84C3: __glXInitialize (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/glxext.c:940) ==3018== by 0x51A49D7: glXGetFBConfigs (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/glxcmds.c:1660) ==3018== by 0x51A5099: glXChooseFBConfig (/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/glxcmds.c:1599) ==3018== by 0x4C386F9: glXChooseFBConfig (in /usr/lib/libGLX.so.0.0.0) ==3018== by 0x109301: main (in /home/name/debug-xwfm4/glxample) ==3018== ==3018== ==3018== HEAP SUMMARY: ==3018== in use at exit: 964,131 bytes in 3,934 blocks ==3018== total heap usage: 8,989 allocs, 5,055 frees, 3,301,060 bytes allocated ==3018== ==3018== LEAK SUMMARY: ==3018== definitely lost: 64 bytes in 2 blocks ==3018== indirectly lost: 0 bytes in 0 blocks ==3018== possibly lost: 80,104 bytes in 537 blocks ==3018== still reachable: 883,963 bytes in 3,395 blocks ==3018== suppressed: 0 bytes in 0 blocks ==3018== Rerun with --leak-check=full to see details of leaked memory ==3018== ==3018== Use --track-origins=yes to see where uninitialised values come from ==3018== For lists of detected and suppressed errors, rerun with: -s ==3018== ERROR SUMMARY: 6 errors from 1 contexts (suppressed: 0 from 0)
This is expected. valgrind does not understand how the ioctl works, so it thinks that uninitialized memory is being read. But that's not an actual issue.
So this is not causing any problems, I suppose it's controlling the hardware by reading/writing to memory addresses provided by the kernel, and valgrind is giving a false positive, thank you for your rapid answer explaining things. I can look at some other things instead then.
(In reply to stratus from comment #2) > So this is not causing any problems, I suppose it's controlling the hardware > by reading/writing to memory addresses provided by the kernel, and valgrind > is giving a false positive, thank you for your rapid answer explaining > things. I can look at some other things instead then. Nope, the issue has nothing to do with that. It has to do with valgrind not understanding how that ioctl() works. That specific one works by the kernel filling in some data structures, but valgrind thinks that the ioctl is being passed data. But that's not the case.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/515.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.