Bug 90194 - Fix Valgrind error in drmPrimeHandleToFD
Summary: Fix Valgrind error in drmPrimeHandleToFD
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: libdrm (show other bugs)
Version: XOrg git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-27 13:48 UTC by Guillaume Desmottes
Modified: 2015-05-28 16:03 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
drmPrimeHandleToFD: initialize args.fd to 0 (849 bytes, patch)
2015-04-27 13:49 UTC, Guillaume Desmottes
no flags Details | Splinter Review
drmPrime*: initialize output args to 0 (1.07 KB, patch)
2015-04-28 14:38 UTC, Guillaume Desmottes
no flags Details | Splinter Review
drmPrime*: initialize output args to 0 (1.07 KB, patch)
2015-04-29 08:15 UTC, Guillaume Desmottes
no flags Details | Splinter Review

Description Guillaume Desmottes 2015-04-27 13:48:14 UTC
args.fd is left uninitialized making Valgrind angry.

==14518== Syscall param ioctl(generic) points to uninitialised byte(s)
==14518==    at 0x3EB84F6407: ioctl (syscall-template.S:81)
==14518==    by 0x3B01803B17: drmIoctl (xf86drm.c:175)
==14518==    by 0x3B01806A7B: drmPrimeHandleToFD (xf86drm.c:2701)
==14518==    by 0xDF0866D: drm_intel_bo_gem_export_to_prime (intel_bufmgr_gem.c:2729)
==14518==    by 0xDA92DF7: intel_query_image (intel_screen.c:563)
==14518==    by 0x32E484E64D: dri3_alloc_render_buffer (dri3_glx.c:926)
==14518==    by 0x32E484E64D: dri3_get_buffer.isra.10 (dri3_glx.c:1307)
==14518==    by 0x32E484F499: dri3_get_buffers (dri3_glx.c:1466)
==14518==    by 0xDAB0486: intel_update_image_buffers (brw_context.c:1475)
==14518==    by 0xDAB0486: intel_update_renderbuffers (brw_context.c:1167)
==14518==    by 0xDAB07B4: intel_prepare_render (brw_context.c:1188)
==14518==    by 0xDAB0906: intelMakeCurrent (brw_context.c:1031)
==14518==    by 0xDA51495: driBindContext (dri_util.c:538)
==14518==    by 0x32E484DAA9: dri3_bind_context (dri3_glx.c:145)
==14518==    by 0x32E481E5E6: MakeContextCurrent (glxcurrent.c:243)
==14518==    by 0x8052F3C: gst_gl_context_glx_activate (gstglcontext_glx.c:401)
==14518==    by 0x8036D51: gst_gl_context_activate (gstglcontext.c:632)
==14518==    by 0x803882C: gst_gl_context_create_thread (gstglcontext.c:1282)
==14518==    by 0x3EBB0703D4: g_thread_proxy (gthread.c:764)
==14518==    by 0x3EB8807529: start_thread (pthread_create.c:310)
==14518==    by 0x3EB850022C: clone (clone.S:109)
==14518==  Address 0xd793a18 is on thread 9's stack
==14518==  in frame #2, created by drmPrimeHandleToFD (xf86drm.c:2695)
Comment 1 Guillaume Desmottes 2015-04-27 13:49:54 UTC
Created attachment 115375 [details] [review]
drmPrimeHandleToFD: initialize args.fd to 0
Comment 2 Emil Velikov 2015-04-28 11:02:58 UTC
Hi Guillaume

With args.fd used for output this seems like a false positive. Alternative solution would be to make Valgrind aware of this. A similar issue exists for args.handle in drmPrimeFDToHandle.

I fear that not many people keep track of bugzilla, so please forward your patch to the dri-devel mailing list [1].

Thanks
Emil

[1] dri-devel@lists.freedesktop.org
Comment 3 Guillaume Desmottes 2015-04-28 14:38:59 UTC
Created attachment 115403 [details] [review]
drmPrime*: initialize output args to 0

Here is a patch for both functions. I agree it's probably a false positive but the fix is simple enough to be worth adding those extra lines and saving people the trouble of debugging those.

I'll send the patch to the list as well.
Comment 4 Pekka Paalanen 2015-04-28 17:07:38 UTC
If you initialize an fd, at least initialize it to the invalid file descriptor -1. Zero is a valid file descriptor and very often already an open one.
Comment 5 Guillaume Desmottes 2015-04-29 08:15:53 UTC
Created attachment 115430 [details] [review]
drmPrime*: initialize output args to 0
Comment 6 Emil Velikov 2015-05-28 16:03:18 UTC
Added an extra memclear(args) for each function and pushed to master.

Thanks
Emil


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.